ghc-whole-program-compiler-project VS haskell.nix

Another thing you can try is the ghc-wpc project which has an interpreter which supports breakpoints, though you may need to hack little a bit to achieve your goals.

Here the goal is to build a high level, easy to understand model for all GHC backend features. Validations is also required. Once we know the semantics of GHC primops and RTS features then it becomes possible to figure out how to compile Haskell programs to GRIN. I started the GHC-WPC project for this reason. GHC-WPC exports the STG intermediate representation for the whole Haskell program, and I wrote an STG interpreter from scratch in Haskell that can run any Haskell program. (i.e. GHC itself) The STG interpreter is the high level model for the GHC primop and RTS semantics. It implements all these in pure Haskell, it does not depend on GHC RTS at all.

I can easily debug any Haskell program with the external STG interpreter. https://www.youtube.com/watch?v=DkDUEd3pUyM https://github.com/grin-compiler/ghc-whole-program-compiler-project

I haven't gotten my hands dirty yet, but really excited hearing GHC-WPC is going on!

Why didn't you mention GHC-WPC? It is also a backend sample. It exports enough information (STG + linker opts + c bits) to interpret the program or to generate a binary executable via the regular GHC codegen system. https://github.com/grin-compiler/ghc-whole-program-compiler-project

You could use the GHC codegen and RTS via the external STG IR. https://github.com/grin-compiler/ghc-whole-program-compiler-project

Remarks: 1. Strict functional languages can be expressed in STG without overhead, because STG has explicit liftedness control. In a strict language every data is unlifted or unboxed. 2. Supporting all GHC primops is not unrealistic. See the primop implementation in the external STG interpreter source code. Here is the implementation of the threading primops.

I'm not a great haskeller but I found haskell.nix better for Haskell projects, like the commenter on Discourse suggested. I've had a few issued regarding package versions with nixpkgs that haskell.nix solved.

FWIW, there's also libraries like haskell.nix that solve the caching problem.

I would try haskell.nix.

If you want to hurt your brain, check out haskell.nix. That's some good stuff right there ^^

The haskell.nix framework is good for this.

One cool thing is that this will enable GHC builds using ucrt instead of vscrt in the future. Concretely, together with NixOS/nixpkgs#171418 and its follow-up NixOS/nixpkgs#173498), this will e.g. allow haskell.nix to upgrade to a newer wine pin for TH cross compilation: https://github.com/input-output-hk/haskell.nix/blob/dd13e822529ae5342494969bce8a457522a60100/overlays/wine.nix

If you are somewhat comfortable with nix: https://github.com/input-output-hk/haskell.nix supports GHCJS 8.10.x (in particular 8.10.7).

I also prefer stack for development, but I use nix to deploy to production. This way, I can install ad-hoc system dependencies locally and play with them during development as well as enjoy the bits and pieces of Haskell ergonomics stack affords, and once I'm happy with what I have, I "nixify" those dependencies as part of the project nix configuration and send them to production without fear. I use IOHK's excellent haskell.nix infrastructure to nixify my stack-based Haskell project, which makes it trivial to maintain a nix configuration that's always in sync with my stack configuration.

And stuff like haskell.nix is supposed to let you configure things with stack or cabal or whatever tool you find most convenient, and let nix do the rest.

/u/ItsNotMineISwear mentioned haskell.nix, which does generate a Haskell package set based on either a stack.yaml file, or the Cabal solver. This would solve some of your problems, but then possibly introduce others.