!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

678 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://nixos.org/manual/nixpkgs/unstable/#haskell | Current PR: https://github.com/nixos/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Ahaskell-updates | Maintainer Docs: https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/HACKING.md | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | Merger Schedule: https://cloud.maralorn.de/apps/calendar/p/H6migHmKX7xHoTFa/dayGridMonth/now | Join #haskell.nix:libera.chat for question about the alternative haskell.nix infrastructure135 Servers

Load older messages


SenderMessageTime
15 Sep 2025
@emilazy:matrix.orgemilyor at least did back in my day13:20:52
@emilazy:matrix.orgemilyhave I mentioned I'm old lately13:21:06
@mangoiv.:matrix.orgMangoIVlike, sure it would if you have checks duplicated all over, things running several times with the same inputs 13:21:06
@mangoiv.:matrix.orgMangoIVand everything being IO 13:21:10
@sternenseemann:systemli.orgsterniwe can just replace the generics / TH instance deriving with a few small m4 scripts problem solved :313:21:35
@teoc:matrix.orgteo (they/he) So once DH is done there's space for TH haha! 13:21:50
@emilazy:matrix.orgemilyfor GHC this unironically seems perfectly adequate. (is the joke that it used to be this)13:22:27
@teoc:matrix.orgteo (they/he) I am genuinely tempted to pitch this for the alternative way to fix the issue with typeclass instances in GHC 13:22:35
@emilazy:matrix.orgemilylike have a damn Python script doing code generation for all I care13:22:54
@emilazy:matrix.orgemilyif it's just for GHC bootstrap13:23:02
@mangoiv.:matrix.orgMangoIVjust use CPP macros? 13:23:05
@teoc:matrix.orgteo (they/he)GHC already has a bunch of these for generating C code13:23:10
@emilazy:matrix.orgemilyok I have an idea13:23:19
@emilazy:matrix.orgemilywhat if we extend this to solve codegen problems too13:23:26
@teoc:matrix.orgteo (they/he) yeah maybe, or python or whatever. I don't mind too much 13:23:29
@emilazy:matrix.orgemilywe would need to use a language that we can trust to be present on all Unix systems13:23:42
@emilazy:matrix.orgemilylike say Perl13:23:45
@emilazy:matrix.orgemilywe could have a Perl script13:23:51
@emilazy:matrix.orgemilyand it could read in assembly code13:23:58
@emilazy:matrix.orgemilyand apply fix-ups. mangling, you could say13:24:17
@sternenseemann:systemli.orgsterni code gen is unironically really nice and it can be down flexibly and simply. In Haskell packgaes it's often not a good option since Cabal doesn't have good support for it (e.g. the preprocessor hack hspec-discover uses is very hacky and breaks recompilation tracking), but GHC already uses autoconf, so you can just pregenerate that with that 13:24:42
@emilazy:matrix.orgemily(does the evil mangler still exist)13:24:52
@mangoiv.:matrix.orgMangoIVthe evil mangler is after code gen though13:25:51
@mangoiv.:matrix.orgMangoIVit mangles assembly13:26:00
@teoc:matrix.orgteo (they/he) I'm quite hopefully about the new Hooks build type. It would be quite nice to use codegen more. Often nicer than TH 13:26:02
@mangoiv.:matrix.orgMangoIVcan it generate scripts for the hooks yet? 13:26:22
@teoc:matrix.orgteo (they/he)cause you get nice introspection for free13:26:25
@sternenseemann:systemli.orgsterniwe'll see how that turns out; when it happened I did not have the energy to look at the proposal at all13:26:44
@mangoiv.:matrix.orgMangoIV afaiu it doesn't seem to fix the problem that external build systems face with Setup.hs, but it may be made to do so. 13:28:10
@mangoiv.:matrix.orgMangoIVThe issue is that you still have to implement the Hooks externally.13:28:19

Show newer messages


Back to Room ListRoom Version: 6