The GHC API

Wish list

This is a wishlist for changes to the GHC API to make tooling easier.

• No landmines in the AST (WIP https://phabricator.haskell.org/D157)
• Full generic support in the AST (comes from the first point)
• Bring in SrcSpanInfo instead of just a SrcSpan to capture syntax noise locations, as per HSE (see discussion https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations), and ghc-exactprint
• Extend the API for renaming/typechecking to better support partial changes
• more parser entrypoints, to explicitly parse fragment. (Merged into GHC 7.10 https://phabricator.haskell.org/D71). See also ghc-parser on hackage.
• ??

Documentation

• The 7.6.1 API docs can be found here.
• A presentation by Thomas Schilling, author of scion: PDF.
• GHC As a Library
• GHC API Status

Issues

1. The API changes between each major GHC release. The changes may not be extensive, but they are often not documented in the release notes
2. The documentation is not always very detailed
3. Some flags can only be set before starting a GHC session, and a GHC session cannot be restarted. This explains the design of buildwrapper: it's an executable that you call for each operation, instead of a long running process. So each call using the GHC API starts a new session, perform the operation, and returns. Not great for performance, but see next point.
4. GHC API uses a lot of memory as you reload files. Things like instances and template haskell make things worse. When EclipseFP used scion, which was a long running process, working on a Yesod app for 2 hours caused scion to use 1Gb of memory.
5. Navigating the AST can be dangerous: depending on the phases you've run on this AST, not all objects are filled in, and accessing an unfilled object result in a panic (see the comments inside the source code of ghc-syb-utils).