| 15 Sep 2025 |
MangoIV | i mean it's only relevant for projects the size of GHC - I don't understand how this seems to be low hanging fruit though. GHC is a mess... | 13:18:02 |
Teo (he/him) | Yeah definitely. As a TH fan, one thing that quite annoys me is that TH isn't proper macros. It's a bunch of disparate features tacked together, and I really want to untangle the mess | 13:18:37 |
emily | conceptually, yes. in practice language features that cordycept the compiler introduce a huge swathe of complexity and compromises unless you design everything around them from the start. because suddenly you have a bunch of exposed and very load-bearing phase distinctions | 13:18:45 |
emily | like how TH makes order of declarations stuff weird as a trivial but gross example | 13:19:09 |
MangoIV | how many GHC.Evil things does GHC use? | 13:19:52 |
Teo (he/him) | idk Generics have been a headache on both of the industrial Haskell codebases I've worked on. Once you have records with more than say 16 fields, it gets pretty bad | 13:19:55 |
emily | also, Haskell is already two full-blown languages at the value and type level (and you can argue there's two or three more in the latter), another layer is just painful :P | 13:20:06 |
emily | no idea. but I wouldn't be surprised | 13:20:23 |
MangoIV | because of compilation speed, right? | 13:20:28 |
Teo (he/him) | yeah compilation speed | 13:20:39 |
MangoIV | also my comment was about GHC itself compiling slowly | 13:20:44 |
emily | especially since you often really want to for perf | 13:20:48 |
emily | or at least did back in my day | 13:20:52 |
emily | have I mentioned I'm old lately | 13:21:06 |
MangoIV | like, sure it would if you have checks duplicated all over, things running several times with the same inputs | 13:21:06 |
MangoIV | and everything being IO | 13:21:10 |
sterni (he/him) | we can just replace the generics / TH instance deriving with a few small m4 scripts problem solved :3 | 13:21:35 |
Teo (he/him) | So once DH is done there's space for TH haha! | 13:21:50 |
emily | for GHC this unironically seems perfectly adequate. (is the joke that it used to be this) | 13:22:27 |
Teo (he/him) | 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 (he/him) | 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 (he/him) | 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 |