Re: cabal design

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 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