Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts
When we write a signature like
package p where signature H where data T
and compile it to an interface file, there are two ways we might say what the
Module of this interface is:
- The **identity module** uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is
p(H -> HOLE:H):H.
- The **semantic module** tells us what the
Names of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is
hole:H, since this signature exports one entity named
hole:H.T. The semantic module can always be derived from the identity module.
For normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules.
By in large, when GHC manipulates
Module directly it is interested in the identity module. However, when a
Module is used with reference to a
nameIsLocalOrFrom), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a
ModIface, need to filter against the semantic module.)
I tried a few ways of factoring GHC's code so we'd be less likely to confuse these two
Modules when typechecking signatures: the big problem is if you're adding a
getModule call to
TcRn, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures.
Here are some things we could do:
- My initial attempt was to change
mi_moduleto record a new data type
TopModulewhich recorded both the semantic and identity module, with
TcRncontinuing to return a semantic module, but
mi_modulereturning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that
getModulereturning the semantic module is always correct.
- My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite
newGlobalBinderso that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules.