Ghc-whole-program-compiler-project Alternatives
Similar projects and alternatives to ghc-whole-program-compiler-project
-
-
-
grin
GRIN is a compiler back-end for lazy and strict functional languages with whole program optimization support. (by grin-compiler)
-
-
haskell.nix
Alternative Haskell Infrastructure for Nixpkgs
-
hackage-server
Hackage-Server: A Haskell Package Repository
-
DocTest
An implementation of Python's doctest for Haskell (by sol)
-
Scout APM
Scout APM: A developer's best friend. Try free for 14-days. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
-
typelevel-rewrite-rules
rewrite rules for type-level equalities
-
normalization-bench
Lambda normalization and conversion checking benchmarks for various implementations
-
manual-stg-experiment
Manually constructed STG programs compiled with the standard GHC codegen backend.
-
tcplugins-zurihac2020
ZuriHac 2020 GHC typechecker plugins project
-
hs-foreign-emscripten
INTERCEPT GHCJS CCALL DISPATCH TO EMSCRIPTEN
-
fused-effects-system
Profiling for Haskell programs without recompiling, via fused-effects.
Suggest an alternative to ghc-whole-program-compiler-project
Reviews and mentions
-
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.
Stats
Are you hiring? Post a new remote job listing for free.