| 15 Sep 2025 |
 emily | we would need to use a language that we can trust to be present on all Unix systems | 13:23:42 |
| emily | like say Perl | 13:23:45 |
| emily | we could have a Perl script | 13:23:51 |
| emily | and it could read in assembly code | 13:23:58 |
| emily | and apply fix-ups. mangling, you could say | 13:24:17 |
 sterni | code gen is unironically really nice and it can be down flexibly and simply. In Haskell packgaes it's often not a good option since Cabal doesn't have good support for it (e.g. the preprocessor hack hspec-discover uses is very hacky and breaks recompilation tracking), but GHC already uses autoconf, so you can just pregenerate that with that | 13:24:42 |
| emily | (does the evil mangler still exist) | 13:24:52 |
 MangoIV | the evil mangler is after code gen though | 13:25:51 |
| MangoIV | it mangles assembly | 13:26:00 |
 teo (they/he) | I'm quite hopefully about the new Hooks build type. It would be quite nice to use codegen more. Often nicer than TH | 13:26:02 |
| MangoIV | can it generate scripts for the hooks yet? | 13:26:22 |
| teo (they/he) | cause you get nice introspection for free | 13:26:25 |
| sterni | we'll see how that turns out; when it happened I did not have the energy to look at the proposal at all | 13:26:44 |
| MangoIV | afaiu it doesn't seem to fix the problem that external build systems face with Setup.hs, but it may be made to do so. | 13:28:10 |
| MangoIV | The issue is that you still have to implement the Hooks externally. | 13:28:19 |
| MangoIV | so while it narrowed the scope, it didn't entirely fix the issue. | 13:28:33 |
| MangoIV | my point was that GHC already supports CPP | 13:29:06 |
| MangoIV | it would be quite embarassing though, if GHC would replace generics with CPP | 13:29:22 |
| emily | btw can you fix cross-building a GHC (instead of building a cross GHC) so that I can delete https://github.com/NixOS/nixpkgs/blob/7201db431d05efb6df0b0ff40cdcae6e419b940d/pkgs/development/compilers/ghc/common-llvm-patches.nix thank you in advance :P | 13:29:27 |
| emily | (just going to assume you do 100% of GHC development and can fix everything) | 13:29:50 |
| emily | I wonder how close to working that PR for it is | 13:30:35 |
| emily | (it would also fix TH right?) | 13:32:01 |
| teo (they/he) | Some folks were working on the stage2 cross patch weekend just gone | 13:32:24 |
| sterni | I am more optimistic that this will be solved by just building all packages manually with Cabal and wiring up the bootstrap in Nix rather than in hadrian. (Which is something I plan to investigate this autumn.) | 13:32:25 |
| teo (they/he) | https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14827 | 13:32:51 |
| emily | oh does that replace https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11444 | 13:33:14 |
| sterni | This would probably mean more GHC patches for 9.14 or so, but those can probably be upstreamed eventually | 13:33:18 |
| teo (they/he) | We would also need TH to run on host or smth and maybe more. It's a whole kettle of fish | 13:33:20 |
| emily | that sounds cool if achievable | 13:33:28 |
| MangoIV | wait, as in, build the entirety of GHC with nix or just let hadrian build single stages only? | 13:33:32 |
