#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