| > 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
