| 15 Sep 2025 |
 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 |
| 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 |
