| 15 Sep 2025 |
 emily | either Lennart bends, Cabal/GHC maintainers do, or it's a fork situation | 13:00:32 |
 MangoIV | I think the one that Lennart won’t support is TH and that can’t be used in GHC either | 13:08:07 |
| MangoIV | Oh well… I guess if it’s used in boot libraries might still be an issue huh | 13:09:17 |
 Teo (he/him) | TH proper isn't used in boot libraries only TemplateHaskellQuotes, which means you don't have to worry about the tricky thing which is running splices | 13:11:13 |
| Teo (he/him) | In the long term, idk if GHC will continue to not use TH. GHC currently uses Generics to derive some of its typeclass instances and it leads to horribly slow compilation. TH would be one way to handle that in a better way. We can't currently use it, but that should be unblocked soon. I think the alternatives would be making Generics not slow, or a new way to derive instances | 13:12:58 |
| emily | IIRC he said no plans for implicit params or magic hash, which sound like things GHC would plausibly use | 13:13:01 |
| emily | though of course magic hash stuff may be dodgy for portability in general | 13:13:11 |
| emily | GHC using TH sounds like it'd make @sternenseemann:systemli.org's day :P | 13:13:37 |
| emily | (I guess it'd be fine as long as cross starts working properly again) | 13:13:57 |
| Teo (he/him) | Yeah GHC using TH is blocked on all the glaring issues with TH cross being solved | 13:14:24 |
| emily | generics being slow enough for TH to seem better depresses me. in the tail end of my Haskell activity I was praying all this new stuff would kill off TH | 13:14:51 |
| emily | I dislike TH very much :) | 13:15:13 |
| MangoIV | What does magichash have to do with portability | 13:16:04 |
| MangoIV | magichash is a purely syntactic extension | 13:16:21 |
 maralorn | Idk. I think the idea of macros/front loading as much as logic as possible to the compile step seems very intriguing to me. | 13:16:46 |
| MangoIV | implicitparams sounds like it is mostly relevant for HasCallStack. you can special case that if you want. | 13:17:01 |
| Teo (he/him) | It's always hard to kill off old code. I basically want to implement something (very vaguely) like Rust's facet for Haskell, and I think that could do it. I've been thinking about this for a while and it hasn't happened yet so we will see if it ever happens | 13:17:26 |
| 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 |
| 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 |
