cabal design

[Frederik Eaton]

> OK, so this manual process is slightly tedious, and maybe upsets the
> current model for ghc --make (which I think currently adds all
> packages in the dependency graph to the namespace for all modules?).
> But it shows that the more minimal extension is feasible and does
> not outlaw any combination of packages.

Also, in my original (too long for even me to read) package mounting
proposal I described the way that I decided to think about these
things, and why I think a modules-only solution won't suffice:
"Modules and packages are quite distinct constructs, modules are
needed for namespace partitioning and packages are needed to delineate
administrative boundaries and sources of change. Both are necessary
and both deserve special consideration ..."

> I do also worry a little that grafting could introduce worse namespace
> problems that we haven't thought of, simply because we haven't had
> a chance to play with it yet.

Yes, this is a concern of mine as well. If people start referring to
packages with different names in their code, as grafting will allow
them to do, then it will be harder for them to share code with each
other. This is one reason why I think default grafting locations will
be important.

> > The thing about (c) is that it'd be a Big Pity if new-style packages
> > couldn't be used with Hugs because they don't obey the unique-module
> > constraint.  Ditto nhc.
> 
> I'd be willing to to implement naming triples <P,M,E> in nhc98,
> on that fabled day when I finally implement a Cabal-style package
> registration tool for nhc98, (which unfortunately won't be anytime
> soon).  The grafting scheme may turn out to be straightforward too,
> but as I've indicated, I'm a bit less keen on it.

You should totally be keen on it. Libraries will be so much more
elegant if their namespaces don't have to contain their names.
Imagine, for instance, not having to think of the name of something
before you start writing it.

Frederik