Packages and modules

Ketil Malde ketil+haskell at ii.uib.no
Fri Jul 7 03:36:20 EDT 2006


Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> writes:

> 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.

This brings up an interesting point: if I need a bugfix from version
X, later packages will probably also be okay.  So it should be
possible to do:

         import A.B.C from "foo >= X"

How about minor/major revisions?

>> 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 thought Simons' (and perhaps also Brian's) still allowed package
juggling from the command line - is that incorrect?  I.e. is "import
from.." intended to be the *only* way of specifying packages?

Cabal lets you specify package dependencies, at least for the program
as a whole - doesn't that mean it would have to rewrite the source
before compilation?

And another issue: presumably the source code is prioritized, so if
the cabal file (or command line) specifies -package foo > v2, but the
sources specify "foo-2.0", the compilation will fail if only foo-2.1
is installed?

Anyway, *if* packages can be juggled at the command line, it should
suffice to say:

        EXTRAFLAGS='-package foo-2.1' make test

> 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

I think you can do this, as long as symbols are annotated with package
names.  Even if only command line options are available, you can do
something like: 

  {-# OPTIONS -package foo #-} -- or replace with myfoo
  module F where
  import Foo

And of course, if you want to change the package for your entire
project (as opposed to a single module), you edit the Makefile,
.cabal, or whatever. 

If you want to mix parts from different versions in the same module,
you can use proxy modules.  Something like this, perhaps:

Foo03.hs:
  {-# OPTIONS -package foo-0.3 #-} 
  module Foo03 (module Foo) where 
  import Foo (foo)

Foo10.hs:
  {-# OPTIONS -package foo-1.0 #-} 
  module Foo10 (module Foo) where 
  import Foo (bar)

Main.hs:
  import Foo03(foo)
  import Foo10(bar)  

-k

PS: Is it correct that -- except for the new functionality in
symbols being annotated with package as well as module name -- all of
this is just a matter of convenience/syntactic sugar?  (Which would
explain the volume of the discussion :-)
-- 
If I haven't seen further, it is by standing in the footprints of giants



More information about the Libraries mailing list