| 15 Sep 2025 |
 emily | and it could read in assembly code | 13:23:58 |
| emily | and apply fix-ups. mangling, you could say | 13:24:17 |
 sterni (he/him) | 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 (he/him) | 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 (he/him) | cause you get nice introspection for free | 13:26:25 |
| sterni (he/him) | 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 (he/him) | Some folks were working on the stage2 cross patch weekend just gone | 13:32:24 |
| sterni (he/him) | 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 (he/him) | 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 (he/him) | This would probably mean more GHC patches for 9.14 or so, but those can probably be upstreamed eventually | 13:33:18 |
| Teo (he/him) | 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 |
| Teo (he/him) | Yeah it's that rebased | 13:33:36 |
| emily | but feels like a heavy lift | 13:33:38 |
 Alex | In reply to @emilazy:matrix.org
IIRC he said no plans for implicit params or magic hash, which sound like things GHC would plausibly use GHC uses both, yes.
They are not too difficult to hack around. (Magic hash is purely syntactical, implicit params is in a sense sugar.) | 13:33:50 |
