import resolution (was RE: exposed packages and cabal depends)

[Wolfgang Thaller]

S. Alexander Jacobson wrote:

> Right now, I can move directory Foo anywhere on my [shared] 
> filesystem, cd into it, and do ghci Main.hs, And, it "just works." I 
> don't need to go through a packaging workflow to do this and I don't 
> think I should!  And, I don't think it is unreasonable to expect this 
> same property to hold for moves between filesystems.

Hmmm... but the meaning of the ghci command itself will change - you 
might have ghc-6.4 on one system, and ancient 5.04 on another and a 
brand-new nightly CVS build on a third machine. Is it reasonable to 
expect all future (and perhaps even past) versions of ghc to behave 
exactly the same?

> Suppose you have a group of developers interacting through cvs or 
> darcs.  You don't want to send out an out of band alert every time you 
> add a dependency on a new package (or package version), you don't want 
> to have a massive installation headache every time you add a 
> development box, and you really don't want to add packaging workflow 
> to commit/checkout scripts.

OK I see your point, but are there any alternatives? It sounds like you 
don't want to have to install packages or libraries at all.
But that would mean that

*) we have to clutter source code with information that IMHO should not 
be there.

I do NOT want to specify a complete URL specifying where to get GHC's 
version of Data.List whenevet I import Data.List.

*) we could never have one package be a drop-in replacement for another

I have compiled & linked the same C program (which says #include 
<GL/glut.h>) against the GLUT library, the freeglut library, and 
Apple's own Mac OS X-specific rewrite of GLUT. This wouldn't have been 
possible if installing library packages was not separate from importing 
library modules.

> Handling of versioning is orthogonal e.g. perhaps we just need 
> DEPRECATED pragmas or perhaps we can use the type system to 
> automatically determine which versions of Data.List are compatible or 
> perhaps we etc.  But this is a dirgession.
>
> Again, my main points is that code shouldn't change meaning depending 
> on context. The meaning of "import Data.List" should not be system 
> dependent.

But unless you specify which exact version you want to use in the 
source code, and have the compiler include every version of Data.List 
ever released, the meaning of "import Data.List" will always be system 
dependent. Just as the meaning of #include <stdio.h> is 
system-dependent. What's wrong with that?


Cheers,

Wolfgang