| > Consider how seemingly simple the current Haskell module system is. | > Yet dealing with the full implications of qualified imports, | > renamings, | > and hidings turned out to be pretty non-trivial when we implementors | > eventually started exercising all the corner cases. I know for a | > fact that Hugs and nhc98 still contain bugs in this area, and the | > subject even merited a Haskell Workshop paper in 2002! Yes, this stuff was trickier than it looked, but it really is orthogonal to the packages proposal, I think. I don't think there are going to be problems here. | > I think it would almost be possible to substitute "top-level name in | > the library hierarchy". That is, instead of uniquely identifying a | > Haskell entity as the triple (gtkhs-0.5, Gtk.Window, widget), I think | > one could get away with the pair (GtkHS_0_5.Gtk.Window, widget) where | > the top-level hierarchy name is derived in some standard (if ugly) | > way from your package name. | | This also occurred to me. But there's a reason for having a two-tiered | system: | | The package namespace is for distribution, dependencies, and | versioning, whereas the module hierarchy is for organising modules | by functionality. Another important aspect is that one does not want to embed version names in your Haskell source code import GTK-1.7.Graphics.UI because that makes it hard to upgrade. The same source code would compile equally well with GTK-1.8 I was talking to Erik Meijer today about the proposal, and it turns out to be remarkably similar to the Common Language Runtime story (except that they call a package an "assembly"). When compiling one says csc /r:foo /r:baz Source.cs where the /r flags are like -package; they bring into scope the exports of assemblies foo and baz. Every assembly has a globally unique name (its "strong name"), rather like our proposed package name. There's no provision for installing foo and baz so they are available without /r flags. There isn't a mechanism yet for grafting packages into different places, but there should be (else you are stuck if foo and baz both define the same namespace). At least some of this is described in Erik's recent CACM paper "What's in a name", which I have not yet read. Simon