Libraries and hierarchies

[Simon Marlow]

Graham Klyne writes:
> At 11:10 01/08/03 +0100, Simon Marlow wrote:
> >You could even use this mechanism, in a per-user=20
> configuration file say,
> >to site the GTK+HS library directly in Gtk.*, if you're too=20
> lazy to type
> >Graphics.UI all the time.  This wouldn't be recommended though: any
> >source code you write won't compile on someone else's system that
> >doesn't have the same convention.
>=20
> It's not clear to me how this final problem is solved in the=20
> general case=20
> of the scheme you describe, unless everybody uses the same=20
> defaults, which=20
> practically speaking I think is pretty much the same as=20
> having a fixed global hierarchy.

We arrived at a solution to this later in the thread:  the idea is that
source code would be distributed with a list of dependencies, of the
form

   [(PackageName,ModulePrefix)]

listing the packages and the appropriate sites (grafting locations) for
those packages.

Given that source code should already be distributed with a list of
package dependencies, this doesn't seem too burdensome.  Furthermore it
can be automatically managed by the library distribution infrastructure.

> Another thing that worries me a little is the apparent=20
> complexity of the=20
> scheme you proposed.  I think a clear and primary goal should=20
> be to make it=20
> easy to install, compile and use any software library from any=20
> source.  Anything less would, I think, negatively impact=20
> take-up of Haskell=20
> as a serious programming tool.

I completely agree.

Perhaps we've made the scheme sound complicated by trying to explain it
in a precise way, and mixing it up with the motivation.  It really isn't
that hard!

But to answer your point above, here is how we're making it easier for
someone to install a software library from source:

  - the library would come with a list of dependencies which are
    *reliable* - they can only have one meaning, because package names
    are globally unique.

  - the dependencies would include version information about the
    packages, which means it is much less likely that you happen
    to get the wrong version of a package and have the build fail (or
    worse, get broken code).

  - there will be an up-to-date list of available packages and where
    to get them on the web.

Also, we're making it easier for someone to write a library:

   - obtaining a unique package name will be easy (details still to
     be worked out).  Compare this with obtaining unique module names=20
     currently: it's an ad-hoc and unsatisfactory scheme.

   - module names within the library source code will be shorter.

Cheers,
	Simon