
On 23 June 2005 10:14, Frederik Eaton wrote:
It looks like there's been a bit of recent discussion regarding module and package namespaces. There is a certain possible design feature that I don't think has been mentioned yet, that I think would be very helpful, so I thought I should at least bring it up.
This idea has been raised before, but it was a while back, and we called it "grafting". Here's the start of the thread, which went on for quite some time: http://www.haskell.org/pipermail/libraries/2003-August/001310.html I suspect that various opinions raised in that thread have now changed (mine included). I'm not sure I can succinctly describe why the idea wasn't adopted - I think it is a combination of the complexity it introduces in the implementations, the feeling that the power to weight ratio is a little too low, and the fact that at the time there were many other issues to resolve in the packaging system without considering grafting. As I said, opinions may have changed, and it might be worthwhile to discuss this again. Cheers, Simon

(By the way, sorry about cross-posting again. People have already replied to just 'haskell@' and just 'libraries@' but I'll try to stick to 'libraries@' after this since it seems that some users' mail clients show them two copies otherwise)
This idea has been raised before, but it was a while back, and we called it "grafting". Here's the start of the thread, which went on for quite some time:
http://www.haskell.org/pipermail/libraries/2003-August/001310.html
Actually it looks like that is slightly different from my idea, perhaps I should have expounded a bit more in my original post. Correct me if I'm wrong, but in my proposal: - grafting/mounting would be done per compilation unit. In yours it seems it would be done per (user, system). - configuration of graft/mount points would be done at compile time, zero or one times per package import option. In yours it would be at package install time. I think my proposal is better. In it there would be no cross-system compatibility issues: since each program would specify where its imported packages get mounted itself, you could write a Haskell program on one system and be assured that someone else could use it on another system without problems. I think this is a rather important property and we shouldn't allow it to be broken - a warning that, as you say, "This wouldn't be recommended though: any source code you write won't compile on someone else's system that doesn't have the same convention" is quite insufficient in my opinion! Plus, I think the ability to remount packages at non-standard locations is an important one, but for the above reason your proposal makes it too dangerous and therefore unusable in practice. Our proposals agree on this point:
The implementation must obey the following rule: When compiling a module belonging to a package, that package is temporarily grafted into the root of the module hierarchy.
It was kind of "implicit" in my proposal though. I think the "alternative design" which is mentioned in your proposal is interesting:
Alternative design: modules in the current package could be specified explicitly, perhaps by prefixing them with '.'. This would avoid the possibility of overlap between the current package and the global hierarchy, at the expense of having to add lots of extra '.'s.
I think that might be a useful feature. Obviously one could introduce the '.' syntax and still allow the present sytax to be used for backward compatibility. Frederik -- http://ofb.net/~frederik/

"Simon Marlow"
, Frederik Eaton wrote:
It looks like there's been a bit of recent discussion regarding module and package namespaces.
This idea has been raised before, but it was a while back, and we called it "grafting".
I concur with Simon that the mounting proposal has similarities to the grafting proposal. I also concur that opinions may have changed since the previous discussion, so it is worthwhile bringing it up again. I also wonder whether (or to what extent) mounting/grafting could address (or conflict with) the question of qualified name exports expressed in this thread: http://www.haskell.org//pipermail/libraries/2004-December/002800.html http://www.haskell.org//pipermail/libraries/2005-March/003390.html Regards, Malcolm

I like your proposal and I think that some form of it should be implemented. Here is the section of my original post where I talk about it:
One further thing, there have been proposals to simplify the importing of collections of modules from a certain point in the namespace, etc. I hope it is realized that they are independent from my proposal. They would not be very useful in implementing my proposal, at least I think any such solution would be far from optimal; and vice-versa. 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 in the ongoing design of Haskell.
I still feel this way. Obviously there is some overlap in functionality but unless you want to either bind what's normally under Graphics.UI.Gtk at the namespace root everywhere in the project, or mount the library at some sort of short prefix like Gtk and use Gtk.Button.label everywhere - and neither of these is really suitable - one can't use package mounting to implement your proposed feature. And as with any other feature which exists within the language, your proposal can't distinguish between modules of the same name coming from different packages, so it couldn't be used to build a program's module namespace by mounting individual package namespaces at specified locations (and allowing these package namespaces to have modules of the same name defined), which is what I'm trying to do. It's like the difference between filesystem mounting and a PATH environment variable. Hope this makes sense. Frederik On Mon, Jun 27, 2005 at 12:20:04PM +0100, Malcolm Wallace wrote:
"Simon Marlow"
writes: , Frederik Eaton wrote:
It looks like there's been a bit of recent discussion regarding module and package namespaces.
This idea has been raised before, but it was a while back, and we called it "grafting".
I concur with Simon that the mounting proposal has similarities to the grafting proposal. I also concur that opinions may have changed since the previous discussion, so it is worthwhile bringing it up again.
I also wonder whether (or to what extent) mounting/grafting could address (or conflict with) the question of qualified name exports expressed in this thread:
http://www.haskell.org//pipermail/libraries/2004-December/002800.html http://www.haskell.org//pipermail/libraries/2005-March/003390.html
Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Tue, 2005-06-28 at 21:43 -0700, Frederik Eaton wrote:
I like your proposal and I think that some form of it should be implemented. Here is the section of my original post where I talk about it:
One further thing, there have been proposals to simplify the importing of collections of modules from a certain point in the namespace, etc. I hope it is realized that they are independent from my proposal. They would not be very useful in implementing my proposal, at least I think any such solution would be far from optimal; and vice-versa. 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 in the ongoing design of Haskell.
I still feel this way.
Obviously there is some overlap in functionality but unless you want to either bind what's normally under Graphics.UI.Gtk at the namespace root everywhere in the project, or mount the library at some sort of short prefix like Gtk and use Gtk.Button.label everywhere - and neither of these is really suitable - one can't use package mounting to implement your proposed feature.
Yes, this is what we would like do. That is allow the user to import the whole collection of Gtk modules with either a short prefix "Gtk" or no prefix so that in their code they can use "Gtk.Button.label" or just "Button.label" rather than us having to export the ugly "buttonLabel". Duncan
participants (4)
-
Duncan Coutts
-
Frederik Eaton
-
Malcolm Wallace
-
Simon Marlow