| 15 Sep 2025 |
 teo (they/he) | I am genuinely tempted to pitch this for the alternative way to fix the issue with typeclass instances in GHC | 13:22:35 |
 emily | like have a damn Python script doing code generation for all I care | 13:22:54 |
| emily | if it's just for GHC bootstrap | 13:23:02 |
 MangoIV | just use CPP macros? | 13:23:05 |
| teo (they/he) | GHC already has a bunch of these for generating C code | 13:23:10 |
| emily | ok I have an idea | 13:23:19 |
| emily | what if we extend this to solve codegen problems too | 13:23:26 |
| teo (they/he) | yeah maybe, or python or whatever. I don't mind too much | 13:23:29 |
| 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 |
