RE: import resolution (was RE: exposed packages and cabal depends)
On 12 April 2005 19:58, S. Alexander Jacobson wrote:
My main goal here is to free the user from the hassle of manual package installation. A module written in one location should "just work" when moved to another.
Rather than expoect modules to "just work" when moved from one location to another, I think it's more reasonable to expect *packages* to just work. This is the basis on which the package system and Cabal is built. 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.
And, if the meaning of module names is parametrized by package then package names should be part of import statements. If packages are purely adminisistrative, then they shouldn't.
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?
PS In my last few posts I assumed you had rejected removing the overlap restriction because that is what I interperted you to have said e.g. here:
We're not going to support this, at least for the forseeable future. It's a pretty big change: every entity in the program becomes parameterised by the package name as well as the module name, because module names can overlap.
http://www.haskell.org//pipermail/haskell/2005-March/015597.html
Ok, I was perhaps a little sronger than I intended in that message. The overlap restriction is there for engineering reasons, it's not a fundamental problem, and one day it might be lifted. FWIW, I think we all agree that it sucks.
And here
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
Did you change your mind or am I misinterpreting?
My position on that hasn't changed. Cheers, Simon
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
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
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
participants (3)
-
S. Alexander Jacobson -
Simon Marlow -
Wolfgang Thaller