irrelevant package

[Serge D. Mechveliani]

On Mon, Jun 13, 2005 at 04:06:39PM +0100, Simon Marlow wrote:
> On 13 June 2005 14:34, Serge D. Mechveliani wrote:
> 
> > I am testing  packages  in  ghc-6.4.
> > I set
> >       docon.cabal,
> > 
> > which declares dependence on `data':     build-depends: data
> > The attempt to build  docon  by
> > 
> >   cd $doconSource
> >   runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst
> >   runhaskell Setup.hs build
> > 
> > produces
> > 
> >   configuring ...
> >   compiling ...
> >   ...
> >   DPrelude.hs:1:0:
> >     Module `DPrelude' is a member of package dumatel-1.2.6.4.
> >     To compile this module, please use -ignore-package
> > dumatel-1.2.6.4. 
> > 
> > These does exist a package  dumatel-1.2.6.4,  and both the above
> > packages have  DPrelude  among the module names.
> > But why does Cabal look into irrelevant package? The dependence is
> > set: only `data'.
> 
> This is "fixed" in newer versions of Cabal.
> 
> However, you are heading for problems here.  When you install a package
> P that includes a module M, you prevent the user from having any modules
> called M unless they say '-hide-package P' (see previous discussions on
> this subject).
> 
> For this reason, we strongly recommend using hierarchical module names.
> 
> At the moment, Cabal "exposes" all the packages it imports.  Perhaps we
> should have an option to install an unexposed package, to allow
> installation of packages that contain non-hierarchical module names.
> Isaac - what do you think?



>   When you install a package
> P that includes a module M, you prevent the user from having any modules
> called M unless they say '-hide-package P' 

?
First, it is very natural to have several common module names among 
the installed packages.

Suppose the user package P depends on P2, P3. To build P, Cabal finds 
the minimal needed set  S  of packages for  P.
For my particular aforementioned example, this should be sufficient. 
Because the packages from  S  occur not to have common module names, 
and  ghc-CVS-current  will find this. Right?

Now, suppose, for some another example, it occurs a clash: P2 and P3
occur in  S  and the name  DPrelude (.hs)  is both in P2 and P3 
(and usually these modules have different interface and 
implementation).
Probably, the Cabal system needs to  warn  about this.
But, of course, it is not difficult for Cabal to distinguish these
two modules. Because it is visible that one is  P2.DPrelude  and 
another is  P3.DPrelude.
So, before compilation, the modules are resolved.
Now, at the compilation stage, it all depends on the import/export
set in the modules.  
And the user may write, for example, like this

  import qualified P2.DPrelude (f)
  import qualified P3.DPrelude (f, g)
  import P4.DPrelude 
  ...

Is this "using hierarchical module names" ?

On ambiguious interface, the compiler reports as usual.
I have impression that the compiler already resolves the module 
interfaces as needed, and that package processig by Cabal should not
add any problem here.
If the compiler cannot resolve the import, it asks: 
" P2.DPrelude or P3.DPrelude ?". The rest is on the user.

I thought, the user has also other ways out (as above), 
besides writing  '-hide-package P...'.  Is this so?

Regards,

-----------------
Serge Mechveliani
mechvel at botik.