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(a)cs.york.ac.uk
Subject: Re: FW: Library Infrastructure Proposal & Home Page
"Simon Peyton-Jones" <simonpj(a)microsoft.com> 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!
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
