[GHC] #9252: Generalize hs-boot files to be more like module signatures

[GHC]

#9252: Generalize hs-boot files to be more like module signatures
-------------------------------------+-------------------------------------
              Reporter:  ezyang      |            Owner:  ezyang
                  Type:  feature     |           Status:  new
  request                            |        Milestone:
              Priority:  normal      |          Version:  7.8.2
             Component:  Compiler    |         Keywords:  backpack
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:              |  Related Tickets:
  None/Unknown                       |
             Test Case:              |
              Blocking:              |
Differential Revisions:  Phab:D130   |
-------------------------------------+-------------------------------------

Comment (by Edward Z. Yang <ezyang@…>):

 In [changeset:"aa4799534225e3fc6bbde0d5e5eeab8868cc3111/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="aa4799534225e3fc6bbde0d5e5eeab8868cc3111"
 Implementation of hsig (module signatures), per #9252

 Summary:
 Module signatures, like hs-boot files, are Haskell modules which omit
 value definitions and contain only signatures.  This patchset implements
 one particular aspect of module signature, namely compiling them against
 a concrete implementation.  It works like this: when we compile an hsig
 file, we must be told (via the -sig-of flag) what module this signature
 is implementing.  The signature is compiled into an interface file which
 reexports precisely the entities mentioned in the signature file.  We also
 verify that the interface is compatible with the implementation.

 This feature is useful in a few situations:

     1. Like explicit import lists, signatures can be used to reduce
     sensitivity to upstream changes.  However, a signature can be defined
     once and then reused by many modules.

     2. Signatures can be used to quickly check if a new upstream version
     is compatible, by typechecking just the signatures and not the actual
     modules.

     3. A signature can be used to mediate separate modular development,
     where the signature is used as a placeholder for functionality which
     is loaded in later.  (This is only half useful at the moment, since
     typechecking against signatures without implementations is not
 implemented
     in this patchset.)

 Unlike hs-boot files, hsig files impose no performance overhead.

 This patchset punts on the type class instances (and type families)
 problem:
 instances simply leak from the implementation to the signature.  You can
 explicitly specify what instances you expect to have, and those will be
 checked,
 but you may get more instances than you asked for.  Our eventual plan is
 to allow hiding instances, but to consider all transitively reachable
 instances
 when considering overlap and soundness.

 ToDo: signature merging: when a module is provided by multiple signatures
 for the same base implementation, we should not consider this ambiguous.

 ToDo: at the moment, signatures do not constitute use-sites, so if you
 write a signature for a deprecated function, you won't get a warning
 when you compile the signature.

 Future work: The ability to feed in shaping information so that we can
 take
 advantage of more type equalities than might be immediately evident.

 Signed-off-by: Edward Z. Yang <ezyang at cs.stanford.edu>

 Test Plan: validate and new tests

 Reviewers: simonpj, simonmar, hvr, austin

 Subscribers: simonmar, relrod, ezyang, carter, goldfire

 Differential Revision: https://phabricator.haskell.org/D130

 GHC Trac Issues: #9252
 }}}

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