7 Sep 2025 |
emily | just a more portable blob one | 21:23:27 |
emily | since you still must go through an unauditable machine-generated C file to start with | 21:23:52 |
emily | maybe someone could implement an interpreter to run MicroHs to start it off though 🫠| 21:24:16 |
emily | https://www.joachim-breitner.de/blog/802-More_thoughts_on_a_bootstrappable_GHC
https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html
| 21:25:12 |
emily | some background reading for anyone considering embarking on this task | 21:25:25 |
Alex | In reply to @emilazy:matrix.org the sad thing about MicroHs is that AFAICT it won't offer a true from-source bootstrap Why not?
It runs fine under Hugs. I've already gotten that working. | 21:28:07 |
emily | that's promising then | 21:28:22 |
emily | although it also means maintaining Hugs to keep it working with newer C compilers :) | 21:28:45 |
emily | but might not be too bad | 21:28:58 |
emily | the Discourse post I linked implies to me that extensions like implicit parameters are WONTFIX, so there may be politics involved in getting GHC to stop using extensions that MicroHs doesn't want | 21:29:48 |
Alex | I'd rather avoid it, but forking or preprocessing to handle such extensions isn't out of the question. | 21:30:43 |
emily | does Hugs even work on x86-64? 🤔 | 21:30:55 |
emily | that's a pretty large indefinite future workload IMO | 21:31:14 |
emily | unless you just accept the bootstrap chain getting longer and longer forever | 21:31:30 |
emily | which has big issues itself | 21:31:36 |
Alex | Potentially, yes, which is mostly why I'd rather not. | 21:31:38 |
emily | e.g. it messes up easy bootstrap of new architectures | 21:31:46 |
emily | since now you have to backport codegen to every version | 21:31:59 |
Alex | Definitely trying to keep the chain as short as possible, but there is always unregisterised GHC if absolutely necessary. | 21:32:34 |
emily | yeah | 21:32:58 |
emily | have you talked with Lennart about this? | 21:33:14 |
emily | it would certainly be cool to see | 21:33:19 |
emily | did you have to patch it for Hugs support? | 21:33:28 |
emily | if you could get bootstrap via Hugs upstreamed to MicroHs and ensure that Hugs builds okay with modern C compilers, then I wonder what it would take to Hugs -> MicroHs + MicroCabal added as an option for the Nixpkgs Haskell package set. (where presumably very little would work, but it would at least be tantalizing incentive to working on closing the gap between that and GHC) | 21:36:12 |
maralorn | What are my old and tired eyes seeing?
┃ > Encountered missing or private dependencies:
┃ > cabal-add >=0.1 && <0.2 (installed: 0.2)
Look at the installed . I have been wishing for that feature for years and have been procrastinating to implement it basically the same time.
| 21:36:26 |
maralorn | This is amazing. | 21:37:05 |
Alex | In reply to @emilazy:matrix.org did you have to patch it for Hugs support? Nope, this is already something Lennart has sorted out.
Though I did, amusingly, have to patch Hugs because it was broken in the Nixpkgs commit I started from (someone else wrote that patch, so no effort on my part). | 21:38:44 |
Alex | In reply to @emilazy:matrix.org have you talked with Lennart about this? I don't think so, but I will try and upstream whatever improvements/fixes I make along the way.
(And I expect there to be a lot.) | 21:39:19 |
emily | well AIUI the upstream build system either compiles the C blob or uses GHC right? | 21:43:23 |
emily | so adding a path to bootstrap via Hugs would be a good step | 21:43:36 |