[GHC] #10723: Make declarations in signatures "weakly bound" until they are used

GHC ghc-devs at haskell.org
Mon Aug 3 16:17:06 UTC 2015


#10723: Make declarations in signatures "weakly bound" until they are used
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                   Owner:  ezyang
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Package system    |                 Version:  7.11
      Resolution:                    |                Keywords:  backpack
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by skilpat):

 The use case you have in mind (which is a good one) sounds exactly like
 one of the motivations for thinning in Paper Backpack. The idea is that
 clients could include only the portion of a larger "signature package"
 that they actually use:

 {{{
 -- using the syntax of the POPL paper
 package containers-sig-3 where
   include prelude-sig-1
   Data.Set :: [...]
   Data.Tree :: [...]
   Data.Graph :: [...]

 package client where
   include prelude-sig-1
   include containers-sig-3(Data.Set)
   M = [import Data.Set; ...]
 }}}

 The result is that `client` has holes for the prelude stuff and for
 `Data.Set`, but not for `Data.Tree` or `Data.Graph` -- assuming `Data.Set`
 doesn't actually make use of (i.e. import) the latter two. So if there's a
 new version of `containers-sig-3` that makes BC-incompatible changes to
 `Data.Graph`, then `client` is totally unaffected and will link against an
 implementation of either version of containers.

 A problem with thinning is that it's highly dependent on the import graph
 of the signature package, which isn't a very good signal to clients what
 kinds of feature selection they can employ in using that signature
 package. But the nice thing is that it allows ex post facto selection of
 signature subpackages, so to speak, after the original author has already
 set it in stone.

 Anyway, back to the proposal at hand. It seems feasible to me so long as
 the usage info is used for warnings rather than for implicitly "thinning"
 a signature package; in other words, so long as it's employed explicitly
 rather than implicitly. For example, the usage info about `containers-
 sig-3` could enable a warning that says "you included `containers-sig-3`
 but didn't use some modules; do you want to annotate the include?".
 Instead, if the usage info enabled the client package to only
 (syntactically) depend on `Data.Set` despite no such annotation, that
 would feel kinda weird IMO.

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


More information about the ghc-tickets mailing list