Skip to content
  • Edward Z. Yang's avatar
    Implementation of hsig (module signatures), per #9252 · aa479953
    Edward Z. Yang authored
    
    
    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: default avatarEdward Z. Yang <ezyang@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
    aa479953