Opened 3 years ago

Closed 20 months ago

#10798 closed feature request (wontfix)

Signatures with only types should not be included in unit keys

Reported by: ezyang Owned by: ezyang
Priority: normal Milestone:
Component: Package system Version: 7.11
Keywords: backpack Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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

Change History (1)

comment:1 Changed 20 months ago by ezyang

Resolution: wontfix
Status: newclosed

While we could do this, it goes against the compiler/package manager separation we've settled on. Best not to.

Note: See TracTickets for help on using tickets.