| 29 Jan 2025 |
 maralorn | It’s just that I regularly fail in overriding boot libraries. | 20:43:35 |
| maralorn | And it shouldn’t necessarily be that way. | 20:43:45 |
 sterni (he/him) | not sure, but I assume also in the last | 20:43:58 |
| maralorn | That whole = null thing confuses the heck out of users. | 20:44:09 |
| maralorn | * That whole = null thing confuses the heck out of users and limits nix composability. | 20:44:19 |
| sterni (he/him) | god what's the point of a -compat package that's only compatible with 9.6 and above | 20:44:24 |
| sterni (he/him) | idk maybe we should just remove the versioned attrbiutes of core packages from the package set | 20:44:49 |
| sterni (he/him) | except for when we need them | 20:44:54 |
| maralorn | Still sounds less predictable than just using them. | 20:45:27 |
| sterni (he/him) | I mean we could try and see what happens if we reinstall the reinstallable packages | 20:45:55 |
| maralorn | I’d say we should do that if we can get away with it. But of course that’s work and I don’t know if it would work. | 20:46:04 |
| sterni (he/him) | but I suspect it's a real nightmare with anything that links against GHC | 20:46:08 |
| maralorn | That’s a good point. | 20:46:26 |
| maralorn | How does that even?^^ | 20:46:42 |
| maralorn | Like with which stage are boot packages compiled? | 20:46:56 |
| maralorn | I mean ghc the lib cannot be compiled by itself of the same stage, right?^^ | 20:47:22 |
 hellwolf | In reply to @maralorn:maralorn.de
As always I have to ask: Why built hlint with ghc910? hlint will work perfectly fine when compiled with older ghcs. If you need support for new syntax the relevant version is that of ghc-lib-parser. some extensions are 9.10+, hlint wouldn't support it. | 20:48:01 |
| hellwolf | * some extensions are 9.10+, hlint built for other version of ghc wouldn't support it. | 20:48:19 |
| hellwolf | that's my understanding | 20:48:23 |
| hellwolf | * some extensions are 9.10+, hlint built for other version of ghc libs wouldn't support it. | 20:48:31 |
| maralorn | Yeah, true. | 20:48:59 |
| hellwolf | And I'm not shy away from using the latest the greatest... so | 20:51:40 |
| hellwolf | but I circumvented and avoided TypeaAbstractions in functions (a ghc9.10 addition) for now | 20:52:42 |
| maralorn | Or is that some kind of fix point where we link a lib compiled with ghc stage-n directly against the lib ghc stage-n? | 20:53:18 |
| maralorn | Oh, boy, why do I know so little about this. 😄 | 20:53:31 |
| maralorn | Really looking forward to using that one. | 20:53:50 |
 Teo (he/him) | In reply to @maralorn:maralorn.de
Or is that some kind of fix point where we link a lib compiled with ghc stage-n directly against the lib ghc stage-n? Iirc stage-2 GHC links against libraries built by stage1 GHC, but that's OK because they are practically the same anyway | 21:58:11 |
| Teo (he/him) | There's this explanation in the Hadrian docs but even with that it's still quite confusing https://gitlab.haskell.org/ghc/ghc/-/tree/master/hadrian#staged-compilation | 22:01:25 |
| maralorn | Ah, thanks that actually helps me. | 22:16:28 |
| maralorn | So even "reinstallable" dependencies of ghc cannot actually be reinstalled when used together with ghc? Because ghc stage 2 is linked with mtl stage 1 and thus will collide with mtl stage 2? | 22:19:49 |
