-- 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
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).
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
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
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.0
wired-in package base mapped to base-4.0.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.0
wired-in package template-haskell mapped to template-haskell-2.3.0.0
wired-in package dph-seq[""] not found.
wired-in package dph-par[""] not found.
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?
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
