On 31/07/2014 15:31, Edward Z. Yang wrote:
We need to rethink the shadowing behaviour. It is designed to handle
the case where we have the same PackageId (name + version) in two
different DBs (e.g. global and local). Shadowing takes the topmost one
of these (e.g. local, or rightmost -package-db flag). We can relax this
requirement so long as the InstalledPackageIds are different, but what
if the InstalledPackageIds are the same? Right now that's OK, because
identical InstalledPackageIds implies identical ABIs, but if we change
that so that InstalledPackageId is derived from the source and not the
ABI, we would not be able to assume that two identical
InstalledPackageIds are compatible.
I talked to Duncan about this, and he's asserted that under a Nix-like
model, equal InstalledPackageIds really would imply identical ABIs.
I think this would be pretty hard to achieve reliably (and if we get
it wrong, segfault); Simon, perhaps you would know more about this.
Right now this is ok, because InstalledPackageIds contain the ABI, but
the proposal we were going to follow (I believe) was to have
InstalledPackageIds contain a hash of the source code. Since GHC
compilation is (still) not deterministic, identical source hashes does
not imply identical ABIs. It would be ok if the InstalledPackageId was
Hash(Source,ABI), though. (or was there some reason we had to know the
InstalledPackageId before compilation?)
Duncan (and shout if I understand wrong) is also keen on abolishing the
shadowing algorithm completely when we have package environments and
making a package environment mandatory (defaulting to a global package
environment when nothing available.) The reason for this is that in a
Nix model, we mostly abolish package database stacks and have a single
global package database, which all packages are chucked into. In this
case, the current shadowing really has no idea how to pick between two
packages which shadow each other in the same database.
Yes, and I agree with Duncan, provided identical InstalledPackageId
implies identical ABI.
Cheers,
Simon
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
