Malcolm Wallace
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