| 15 Sep 2025 |
 emily | well half the time you turn it on to import some GHC.Evil is my point | 13:17:39 |
 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 |
