Global type env for the module we are compiling now. All TyCons and Classes (for this module) end up in here right away, along with their derived constructors, selectors.

(Ids defined in this module start in the local envt, though they move to the global envt during zonking)

What is defined in this module and what is used. The latter is used to generate

(a) version tracking; no need to recompile if these things have not changed version stamp

(b) unused-import info

Locally-defined top-level names to keep alive.

Keep alive means give them an Exported flag, so that the simplifier does not discard them as dead code, and so that they are exposed in the interface file (but not to export to the user).

Some things, like dict-fun Ids and default-method Ids are born with the Exported flag on, for exactly the above reason, but some we only discover as we go. Specifically:

• The to/from functions for generic data types
• Top-level variables appearing free in the RHS of an orphan rule
• Top-level variables appearing free in a TH bracket

Home-package Dfuns actually used.

Used to generate version dependencies This records usages, rather like tcg_dus, but it has to be a mutable variable so it can be augmented when we look up an instance. These uses of dfuns are rather like the free variables of the program, but are implicit instead of explicit.

True = Template Haskell syntax used.

We need this so that we can generate a dependency on the Template Haskell package, becuase the desugarer is going to emit loads of references to TH symbols. It's rather like tcg_inst_uses; the reference is implicit rather than explicit, so we have to zap a mutable variable.

Domain is all directly-imported modules The ModuleName is what the module was imported as, e.g. in import Foo as Bar it is Bar.

The Bool means:

• True => import was import Foo ()
• False => import was some other form

Used

(a) to help construct the usage information in the interface file; if we import somethign we need to recompile if the export version changes

(b) to specify what child modules to initialise

We need a full ModuleEnv rather than a ModuleNameEnv here, because we might be importing modules of the same name from different packages. (currently not the case, but might be in the future).

Home-package modules needed by the module being compiled

It doesn't matter whether any of these dependencies are actually used when compiling the module; they are listed if they are below it at all. For example, suppose M imports A which imports X. Then compiling M might not need to consult X.hi, but X is still listed in M's dependencies.