TyCon and DataCon

Our goal is to generate new type declarations from within HERMIT. The initial motivating example is defunctionalization, during which we need to create a data type for the explicit closures. Long-term, however, we'd like to allow adding just about anything to the current module.

Building the TyCon and DataCon structures and populating mg_tcs seems to be the necessity. The Tidy and CG passes generate the bindings for implicit things, and both of those are downstream of our plugin.

Objectives:

• Avoid duplicating much from the GHC API (could lead to GHC patches)
• Expose nice abstractions via the HERMIT API/shell
• Support all declarations

Overview of Relevant GHC API

• https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DataTypes

• basic data types types/TyCon.lhs and basicTypes/DataCon.lhs

• restrictions for TyCon names https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType

• The mg_tcs field holds data declarations; grepping gives hits in typecheck (cf tcg_tcs), vectorise, and tidyPgm

• things to possibly mimic:

  • typecheck/TcTyClsDecls.lhs builds TyCons from HsSyn
  • vectorise/Vectorise/Type/TyConDecl.lhs builds TyCons from other TyCons
    • though much of this work seems to be done by earlier passes; cf mg_vect_decls and mg_vect_info

• see Note [Data Constructor Naming]

  • "worker data con(structor)" deals with unpacking, etc; sometimes called "rep con"

• see Note [Data type families]

  • "rep(repsentation) ty(pe) con(structor)" deals with data (and type?) families

building TyCons

• TyCons are mutually recursive with their DataCons (if they have them)

• basicTypes/DataCon.buildAlgTyCon - pure

• iface/BuildTyDecl.buildDataCon - forall m n (TcRnIf m n); just for uniques and the name cache

Can we just invoke the normal parser?

No. The FastStrings from parsing the original module will differ from the FastStrings from parsing the additional syntax. This because the plugin will have its own FastString.string_table, separate from that of the host compiler image. There may be more obstacles, but that is the first that I have found that would seem to require a GHC patch.

cf simplCore/CoreMonad.reinitializeGlobals and FastString.string_table

I've emailed ghc-devs about this etc.

Long-Term

With respect to adding a data type, I see two options for the basic interface between HERMIT and the GHC API.

1. directly build the DataCon and TyCon data structures ourself (mimic vectorise)
2. build (something like) an HsSyn representation of the data type, set up a mini-typechecker environment, and have the typechecker build the internal data structures

We agreed on 18 June 2013 to start with the most basic stuff. On the other hand, I think option two is a more likely long-term target, since it would handle kind- and type-inference for us. Added bonus: it would provide actual kind- and type-checking.