Signatures with only types should not be included in unit keys

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.)

Trac metadata

Trac field	Value
Version	7.11
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Package system
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture