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