base 3 + base 4 compatibility?

[Simon Marlow]

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