[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