haskell.nix
ghc-whole-program-compiler-project
Our great sponsors
haskell.nix | ghc-whole-program-compiler-project | |
---|---|---|
15 | 9 | |
524 | 115 | |
1.7% | 1.7% | |
9.7 | 8.8 | |
7 days ago | 6 months ago | |
Nix | Haskell | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
haskell.nix
-
Why does Nix have Haskell packages that are incompatible with GHC for a given version?
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.
-
Simple GHC stack for a novice
FWIW, there's also libraries like haskell.nix that solve the caching problem.
-
Any up-to-date cross-compiling methods for Raspberry Pi?
I would try haskell.nix.
-
Take the Nix Pill
If you want to hurt your brain, check out haskell.nix. That's some good stuff right there ^^
-
Trying to build a statically linked binary against glibc (Linux)
The haskell.nix framework is good for this.
-
GHC 9.4.1 Windows changes
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
-
How to make stack work like it's supposed to
I've been using IOHK's alternative infrastructure for this reason. It has its quirks but I've been happier with it. Before that I think I was using developPackage from the nixpkgs haskell tooling which had some introspection ability. You may consider trying that out. But as I remember this will not abide by your version bounds.
-
Announcing `safe-coloured-text`
There's a lot to like here. Alas, despite minimal dependencies, terminfo is somehow uniquely problematic in haskell.nix.
- A question about the current state of Haskell running natively on Apple silicon:
-
Memory from finished thread is not getting reclaimed
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).
ghc-whole-program-compiler-project
-
Can GHCi be run like PDB?
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.
-
ELI5: Why does the new Javascript backend need to live in GHC instead of consuming GHC-WPC output?
If I understand the new GHCJS backend correctly, it diverges from the normal compilation pipeline at STG (see the new StgToJS module subtree). Wouldn't that make it an excellent candidate to use GHC-WPC's machine-readable external STG representation, instead of hooking it directly into the GHC source tree?
-
Haskell compiled onto LLVM increase performance?
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.
-
Why is the debugger so bad in Haskell? (or is it just me)
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
-
Haskell program inspector tooling development
Hello, I'm using the external STG interpreter to observe the runtime behaviour of Haskell programs. Lately I've added an initial call-graph construction feature that I plan to refine further. https://twitter.com/csaba_hruska/status/1417486380536582151 Is there anyone who has dynamic analysis related research ambitions and wants to study Haskell program runtime behaviour in detail? If so then it would be great to talk.
-
What are you hyped about today?
I haven't gotten my hands dirty yet, but really excited hearing GHC-WPC is going on!
-
GHC Pluggable Backend?
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
-
Transpiling to GHC Core language
You could use the GHC codegen and RTS via the external STG IR. https://github.com/grin-compiler/ghc-whole-program-compiler-project
-
Next-gen Haskell Compilation Techniques
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.
What are some alternatives?
Cabal - Official upstream development repository for Cabal and cabal-install
IdrisExtSTGCodegen
nix-doom-emacs - doom-emacs packaged for Nix
hs-foreign-emscripten - INTERCEPT GHCJS CCALL DISPATCH TO EMSCRIPTEN
static-haskell-nix - easily build most Haskell programs into fully static Linux executables
grin - GRIN is a compiler back-end for lazy and strict functional languages with whole program optimization support.
polysemy - :gemini: higher-order, no-boilerplate monads
ghc-dump - A GHC plugin and library for analysing GHC Core
frp-zoo - Comparing many FRP implementations by reimplementing the same toy app in each.
ghc-wpc - GHC-WPC is an extended GHC that exports the STG and other IR (.modpak) for the compiled modules and linker metadata (.ghc_stgapp) at application link time.
nixpkgs - Nix Packages collection & NixOS
hint - Runtime Haskell interpreter