A look across the pond: a comparison between GHC and Racket compilation models
summary
GHC’s workflow requires running cabal and GHC subprocesses, using commands like GHC pkg dump and cabal build --write-ghc-environment-files, and sometimes writing a 50-line Racket script to locate Haddock HTML; Google generate --local still misses local packages. Racket instead exposes stable runtime APIs that return paths and metadata (examples: package-directory, module->exports, xref-index), compiles modules to native blobs on load, and provides reusable tools like the macro-stepper. Proposal: extract small, stable GHC/Haddock kernels for shared tooling.
AI-written summary · about
chapters (9)
- 0:00Haskell vs Racket ecosystems
- 1:23Haskell tooling frustrations
- 5:14Racket tooling strengths
- 7:20GHC vs Racket models
- 11:16Racket compilation server
- 14:46Racket unified tooling API
- 18:57Racket tooling inversion
- 20:42Racket vs GHC API stability
- 21:46Q&A
related talks
34mHackett: a metaprogrammable Haskell
01h 22mGetting Up and Running, and Contributing to GHC
37mStanding on the Shoulders of Giants
45mLanguage-Oriented Programming with Racket
23mMacro-embedding Compiler Intermediate Languages in Racket
01h 03mModern Macros
48mRapid Programming Language Prototypes with Ruby RACC
17mMacros for Domain-Specific Languages