Packages and modules

Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk
Thu Jul 6 10:18:45 EDT 2006


Ketil Malde <ketil+haskell at ii.uib.no> wrote:

> > If a module M imports A.B.C, and I can see two such modules called
> > A.B.C, then the meaning of the code is ambiguous and ill-defined.
> 
> Surely this depends on the relationship between the two A.B.C., and I
> think you make the underlying assumption that they implement different
> things. 

No, I agree that they may be essentially the same module, but one of
them has a bugfix, or a new API call, or something.

> Now, to be able to test my version without rewriting all client code,
> I'd much rather do this substitution from the command line; 
>     ghc -hide foo -package myfoo ...

With the Simons' proposal, and with Brian's, you would need to edit the
source code at all usage positions of "import A.B.C".  I agree that this
is tedious and undesirable.  With my proposal, you could organise your
source code such that only a single file might need to be edited,
replacing say
    module Foo (namespace F) where
    import namespace "foo" as F
with
    module Foo (namespace F) where
    import namespace "myfoo" as F

> Another case that nobody seem to have mentioned, is what happens if I
> move a module from one package to another.  Say somebody finds out
> that 'base' is getting crowded, and wants to move Data.Set to
> 'collections'.   Annotated imports would then have to be updated,

Again, I believe my proposal would permit a single update, whilst the
other proposals would require multiple updates.

    http://hackage.haskell.org/trac/ghc/wiki/GhcPackagesWithGrafting

> PS: Talking about module A.B.C seems a bit abstract.  Perhaps the wiki
> page could be updated with some examples of namespace collisions that
> people have experienced?

One thing I would very much like to be able to write is regression
testing over libraries.  Does the computation P using package HaXml-1.15
give the same result as running P with package HaXml-1.13?  At the
moment, one cannot write such a test directly in Haskell, one must
escape to a separate test harness.

Regards,
    Malcolm


More information about the Libraries mailing list