FW: Library Infrastructure Proposal & Home Page

[Simon Marlow]

Malcolm Wallace writes:

> "Simon Peyton-Jones" <simonpj at 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!

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