RE: FW: Library Infrastructure Proposal & Home Page

Malcolm Wallace writes:

"Simon Peyton-Jones" writes:

...

I'd like to be confident that the package-description proposals that Simon and I have put out isn't incompatible in some way with NHC.

I have been thinking about your proposal for packages, and although there are many aspects of it that I like, and it isn't incompatible with nhc98 as such, my gut feeling is that one particular aspect of it is actually a very large semantic change/addition, and would probably involve a significant amount of work to implement. I mean this change:

An entity in a Haskell program was previously uniquely identified by its (module name, identifier) pair, where the module name is the module in which the entity is defined. This now becomes a triple: (package name, relative module name, identifier)

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!

FWIW, I agree. This has been troubling me for some time, and I think this is the reason that the packages proposal hasn't been greeted with widespread enthusiasm, despite Simon's & my attempts to simplify it.

My feeling is that the latter might apply. For instance, where in your proposal you have chosen the new concept of "package name", 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. We long ago decided that the module hierarchy should be used for organising by functionality only. It doesn't seem right to start using it for the meta-properties of libraries too. (I guess I'm prepared to be persuaded otherwise here - there's the argument that having both namespaces can be confusing and is potentially redundant). Certainly the dependencies of a library are an essential part of the library itself, so arguably they should be present in the source (including version information), however they are also required by the packaging/building/distribution infrastructre, so keeping them separate is likely to be more convenient. Having said all this, the subject of grafting is orthogonal to whether we have a separate namespace for rank-2 modules. I consider the facilities that packages give us (versioning, unambiguous dependencies etc.) rather more important than grafting. Grafting essentially gives you a way for both source code and binary code to be independent of its absolute location in the module hierarchy. It would probably be enough to have a mechanism whereby only source code is independent of its absolute location. Ideas for relative module names have been floated before - perhaps someone would like to make a concrete proposal? Cheers, Simon