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
Name
s 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 ishole:H
, since this signature exports one entity namedhole: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 Name
(primarily 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 Module
s 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
tcg_mod
,mg_module
andmi_module
to record a new data typeTopModule
which recorded both the semantic and identity module, withgetModule
inTcRn
continuing to return a semantic module, butmi_module
returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear thatgetModule
returning 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
nameIsLocalOrFrom
,externaliseAndTidyId
,initIfaceTcRn
,newGlobalBinder
so 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.
Pretty delicate.
Trac metadata
Trac field | Value |
---|---|
Version | 7.10.1 |
Type | Task |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Package system |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |