| 15 Sep 2025 |
 bglgwyng | it seems that the result of callCabal2Nix is not overridable, and I should wrap it manullay to make it overridable. | 04:16:42 |
| bglgwyng | Yes, the vanilla pkgs.haskellPackages.* things are overridable and my callCabal2Nix results are not overridable. And I just found that make-package-set applies makeOverridable manullay. | 04:19:02 |
 Alex | In reply to @bglgwyng:matrix.org
it seems that the result of callCabal2Nix is not overridable, and I should wrap it manullay to make it overridable. At the very least, most of the functions from haskell.lib and haskell.lib.compose should be able to override it (try looking at how they do it?)
That is, unless you use things like buildFromSdist which IIRC prevent further overrides because of how they work. | 10:56:42 |
 sterni (he/him) | Seems like MicroHs is getting more serious about being usable for general purpose stuff, could maybe be interesting to try and add a microhs package set for variety. https://discourse.haskell.org/t/microhs-and-hackage/12916. However, the approach Lennart is taking is a bit questionable. For packages that don't accept MicroHs patches, MicroCabal automatically replaces them with an entirely different package (e.g. random-mhs instead of random). The package descriptions seem to rely on this as well, e.g. you can't build the random-mhs test suite with GHC/Cabal since it declares a dependency on random instead of random-mhs (though maybe that's just a mistake). | 12:23:43 |
 emily | we talked about this recently and I suggested a package set would be interesting for exploring future GHC bootstrap | 12:26:04 |
| emily | especially since we can have MicroHs bootstrap from hugs | 12:26:15 |
| emily | @alex:tunstall.xyz has that Nixified apparently | 12:26:28 |
| sterni (he/him) | should be testu-01, not testu01 from your example? | 12:26:50 |
| sterni (he/him) | bglgwyng: override allows you to use the result of callPackage and call the underlying lambda again with different argument, completely recomputing the value: https://github.com/NixOS/nixpkgs/blob/f501ecd2f4b1b8c4f43fee3f1d5cf3e758c2e166/lib/customisation.nix#L116-L208 | 12:28:43 |
| sterni (he/him) | You can of course not change the underlying function. I'm not entirely sure what you are trying to do. | 12:29:10 |
| Alex | Sure, I can contribute a package set later this week.
There might be a fair bit of flux from frequent upstream changes, but I doubt that'll be much of an issue. | 12:53:41 |
| emily | why does it need its own Cabal btw? | 12:56:19 |
| emily | is real Cabal not flexible enough? can't build with MicroHs? | 12:56:28 |
 chreekat | Yeah it relies on many language extensions that Lennart doesn't plan to support | 12:58:13 |
| emily | this is my fear with the GHC bootstrapping plan... | 13:00:07 |
| 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 |
