Claus Reinke wrote:
-- pretend we're loading a package that depends on base 3 into a
-- session that otherwise depends on base 4
$ ./ghc-6.11.20081004/bin/ghcii.sh -package base-3.0.3.0
-ignore-dot-ghci
..
Prelude> :m +Data.Generics.Basics
Could not find module `Data.Generics.Basics':
it was found in multiple packages: base-3.0.3.0 syb
Even if there was syntax to add one of the two modules (temporarily
hiding one of the packages resets the session, <package>:<name> isn't
accepted), all of ghci would then have to disambiguate (in output and
input) between the imported items and others of the same name, where
a qualified name is no longer sufficient, eg
base-3.0.3.0:Data.Generics.Basics.Data
base-4.0.0.0:Data.Data.Data
GHC is behaving correctly here, isn't it? If you want to use base-3
with GHCi or --make you probably ought to use -hide-all-packages and
specify exactly which packages you want in scope.
I'm not sure exactly what it is you want to happen instead. Could you
elaborate?
I'll try - here is the scenario I had in mind:
- package A depends on base-3
- package B depends on base-4+syb
- I want to use ghci to work on package C's code, where C depends on A+B
This should all work fine. If C depends on base-3, then you'll need to say
'ghci -hide-all-packages -package base-3.0.3.0 ... C.hs'.
Cabal really should invoke GHCi for you, because here we're asking the user
to do some of the work that Cabal already knows how to do, that is, figure
out what -package flags to give to GHC for their package. I suppose you
can always say 'cabal build -v', cut-and-paste the ghc command line and
replace 'ghc' by 'ghci'.
Now, it seems I cannot refer to Data.Generics.Basics in a ghci session
for C, even if that is what A is refering to, because both base-3 (via A)
and syb (via B) are loaded, so the name is ambiguous (even if it ultimately
refers to the same things).
Yes, and that's the right thing. By invoking GHCi without
-hide-all-packages, you're taking the current session from the packages
that are "exposed", which probably corresponds to the most recent version
of everything installed (but it doesn't have to). Exposed packages are
just a hack so you don't have to give -package flags to GHCi in the common
cases.
That means I cannot use -hide-package&co, or so I thought. The best I
can hope for is that there is a unique common ancestor module, and that
I happen to know that I should look there, not in the modules that
re-export this ancestor in different packages. For instance, of the
following three, I
can only name the first in that ghci session:
base-4:0.0.0:Data.Data
base-3.0.3.0:Data.Generics.Basics
syb-0.1.0.0:Data.Generics.Basics
I think you're making everything sound more complicated than it really is!
There's nothing special going on here.
Interestingly, when I try it out, it seems that I can hide base-3.0.3.0,
even
while working with a package that depends on it (such as QuickCheck). In
fact, if I try ':m +Data.Generics.Basics' in a 'ghci -package QuickCheck'
session, the hiding happens implicitly:
$ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghcii.sh -package QuickCheck
GHCi, version 6.11.20080925: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package base-3.0.3.0 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.1 ... linking ... done.
Loading package random-1.0.0.1 ... linking ... done.
Loading package QuickCheck-1.1.0.0 ... linking ... done.
Loading package ghc-paths-0.1.0.5 ... linking ... done.
Prelude> :m +Data.Generics.Basics
Prelude Data.Generics.Basics> :set -v
hiding package base-3.0.3.0 to avoid conflict with later version
base-4.0.0.0
GHC notices when there are multiple packages of the same name exposed, and
hides one of them. It has done this for a long time (probably back to 6.6,
I think).
So it seems that you've already thought of this, and the strategy is to
hide
the intermediate package base-3.0.3.0 and to work directly in base-4.0.0.0
and syb. I was just confused because the behaviour is rather different
in a 'ghci -package base-3.0.3.0' session (repeated at the top of this
message).
Is that difference intended?
Nope, there's nothing different going on. When you ask for base-3.0.3.0,
GHC hides base-4, and vice-versa.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
