Proposed: Language.Haskell.TH.Internal

[Richard Eisenberg]

Hi devs,

This is a brief proposal for an internal, non-user-facing restructuring of the implementation of Template Haskell. It's here (instead of at ghc-proposals) because it's not user-facing.

When a user writes a TH quote [| foo bar baz |], GHC must desugar that into some Core code that builds a Q Exp. This is currently done by calling functions in Language.Haskell.TH.Lib, which is capable of building all the TH abstract syntax. However, many end-users of TH *also* import Language.Haskell.TH.Lib and use its functions. This means that, as the Haskell AST evolves, we can't reasonably evolve this Lib module, as it breaks user code. (There is a requisite amount of churn in TH, but we try to avoid gratuitous changes in Lib.) This has bitten in the past when we have, say, changed the representation of type families to accommodate closed type families, and it's biting now as we (ahem, Ryan Scott) are trying to merge types and kinds in TH.

I thus propose a new module Language.Haskell.TH.Internal. This will start out as a slimmed-down copy of Lib (slimmed-down because Lib already has a bunch of now-disused functions) but may evolve independently. Desugaring quotes will go via this new Internal module, and we will have no qualms about changing its interface, as it's Internal.

What do we think? Ryan has already implemented this idea in D3751.

Pros:
 - Flexibility
 - Separation between user-facing interface and internal interface

Cons:
 - More stuff
 - We already break the TH API with every release; maybe it's not so bad to break more of it.

Thanks,
Richard