[GHC] #10798: Signatures with only types should not be included in unit keys

[GHC]

#10798: Signatures with only types should not be included in unit keys
-------------------------------------+-------------------------------------
              Reporter:  ezyang      |             Owner:  ezyang
                  Type:  feature     |            Status:  new
  request                            |
              Priority:  normal      |         Milestone:  ⊥
             Component:  Package     |           Version:  7.11
  system                             |
              Keywords:  backpack    |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
             Test Case:              |        Blocked By:
              Blocking:              |   Related Tickets:
Differential Revisions:              |
-------------------------------------+-------------------------------------
 Suppose we want to modularize the dependence on `p` in this program:

 {{{
 unit p where
   module A where
     data T = T
     mkT = T
 unit q where
   include p
   module B where
     import A
     bar = mkT
 }}}

 The obvious signature to write for `A` is:

 {{{
 signature A where
   data T
   mkT :: T
 }}}

 But this presupposes an implementation of `A` which exports `T`. But `B`
 doesn't use any export of `T`, and an equally valid implementation would
 be if `T` was defined in some `Types` module and then imported here.

 But suppose we change our signature to be:

 {{{
 signature A.Types where
   data T
 signature A where
   import A.Types
   mkT :: T
 }}}

 This is maximally general, but requires that the module which exports `T`
 be named `A.Types`. If someone puts the type anywhere else, we have to
 rename the signature to the real place it was defined, or make a dummy
 implementation module which reexports the type in question.

 Now there is a curious thing, which is that the choice of module we use to
 fill these extra signature modules currently influences the type identity
 of anything else in the unit. But we never rely on any code from these
 signatures: if I make two distinct dummy modules to set `T` to the same
 type, this really shouldn't have any impact (at all!) on the code
 generated.

 So, my suggestion is that if a signature contains only types (perhaps they
 could be named something else, like `tysignature`), they should not count
 towards the calculation of a unit key. This means that a user can freely
 create dummy modules to fill in these types when they are instantiating;
 all that is being done is helping Backpack figure out what the identities
 of types are. (If we wanted to be fancy, Backpack could even look inside
 type signatures to determine some types, but let's not go there for now.)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10798>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler