Comments from Malcolm Wallace on the packages proposal
-----Original Message-----
From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk]
Sent: 29 September 2003 04:23
To: Simon Peyton-Jones
Cc: Colin.Runciman@cs.york.ac.uk
Subject: Re: FW: Library Infrastructure Proposal & Home Page
"Simon Peyton-Jones"
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! The newly proposed package system seems to be a mechanism that does a similar job to the existing module system, but at one level up. Instead of managing the /value/ namespace, It brings whole /modules/ into scope, and allows qualification, renamings, and hidings at the module layer. In other words, it is a rank-2 module system. I'm not confident that it will be any easier to implement, nor analytically tractable, than the current first-order module system. Should we be looking for some generalisation towards rank-n module aggregation? Or conversely, can we show that rank-2 modules (packages) can always be re-expressed (albeit unpleasantly) by simpler rank-1 modules? 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. With this simple modification, it becomes possible to implement package "grafting" using solely the current module system. e.g. a wrapper module like module Graphics.UI.Gtk.Window (module GtkHS_0_5.Gtk.Window) where import GtkHS_0_5.Gtk.Window could be automatically generated for each grafting point. The only clever part of the package system would be to manage these auto-coded stubs, a far easier task than implementing rank-2 modules. (For instance a clever compiler could choose to generate "virtual" grafting module stubs on-demand, with no real existence in the filesystem, whilst a simpler compiler might just store them as real files.)
Closely related are Isaacs proposals re packaging and distribution (below). I'm not sure there's been any NHC input into that discussion so far, and again I'd like to be sure that we don't accidentally make things hard for NHC.
Issac has been in private contact a number of times w.r.t. his proposal. I don't see any particular nhc98-related problems with his distribution and management mechanisms. Of course it is implementation work that I may not have sufficient spare time to keep up with, but I don't foresee any in-principle difficulties ahead there. Regards, Malcolm