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

[S. Alexander Jacobson]

Simon,

My fundamental point here is that the meaning of code shouldn't change 
depending on the location where it is interpreted.  Otherwise, you get 
untracked dependencies on the local system, limiting sharing and 
portability.  Concretely, the meaning of "import Data.List" in a 
haskell module shouldn't depend on whether the module is on my 
computer or yours.

On Wed, 13 Apr 2005, Simon Marlow wrote:
> Rather than expect modules to "just work" when moved from one 
> location to another, I think it's more reasonable to expect 
> *packages* to just work.

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.

> This is the basis on which the package system and Cabal is built.

Using a package system may make sense when you want to *publish* code, 
but it adds massive overhead when you simply want to share it.

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.

> Build and run dependencies are more than just the modules that the
> source code imports.  Take a look at what's in a Cabal description:
> you'd need to put most of that in the source code to make portable
> modules.  It's not practical, and I argue that the source code is the
> wrong place for that stuff.

Again, code shouldn't change meaning depending on context.  If there 
is stuff in Cabal descriptions that is changing the meaning of code, 
it belongs in the source and not in the metadata.

However, looking at the actual Cabal description spec, I see a lot of 
functionless metadata tags, a bunch of tag alternates for source code 
pragmas, and a bunch of tags for building C(!) libraries.

The only cabal tag, I can see, that actually affects the meaning of 
code is "build-depends." And, it is specifically "build-depends" to 
which I am objecting in this thread.

> Yes, modules are parameterised by package, but no, I don't agree that
> packages should be specified in the source code.
>
> You really don't want to have to write
>
>   import base>=1.0 Data.List
>
> all over the place.  Or maybe you do?

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.

-Alex-

PS You said in this message that "modules are parameterised by 
package," but you also said:

>>    Also, the Haskell module hierarchy is supposed to reflect
>>    functionality, whereas package names are purely administrative.
>>    This is a reason for not including package names in source code.
>>
>>    http://www.haskell.org//pipermail/libraries/2005-April/003513.html
>>
> My position on that hasn't changed.

If packages are purely administrative, they shouldn't be changing the 
meaning of code.  And if they are changing the meaning of code they 
are not purely administrative.  It certainly feels like your position 
has changed....


______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com