import resolution (was RE: exposed packages and cabal depends)
simonmar at microsoft.com
Wed Apr 13 07:23:39 EDT 2005
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.
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.
> Did you change your mind or am I misinterpreting?
My position on that hasn't changed.
More information about the Libraries