Libraries and hierarchies

[Graham Klyne]

At 11:06 11/08/03 +0100, Simon Marlow wrote:
>Graham Klyne writes:
> > At 11:10 01/08/03 +0100, Simon Marlow wrote:
> > >You could even use this mechanism, in a per-user
> > configuration file say,
> > >to site the GTK+HS library directly in Gtk.*, if you're too
> > 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.
> >
> > It's not clear to me how this final problem is solved in the
> > general case
> > of the scheme you describe, unless everybody uses the same
> > defaults, which
> > practically speaking I think is pretty much the same as
> > 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.

Ummm... OK, let's see if I follow, by example.  It sounds a bit like a Unix=
=20
file tree, where new
filesystems can be grafted (mounted) at any point in the tree.  I could=20
imagine a Web-based filesystem in which a URI (which is, by definition,=20
globally unique) can be mounted at any point in the file tree, and then=20
accessed using the a "local" filename.  Close?

In principle, this sounds great, but a fret a little about the practical=20
deployment.  I use Linux a little, but am not by any means a Unix/Linux=20
expert, and I find that I get *very* confused by the difference in=20
directory structures used by different software packages and/or operating=20
system distributions  (er, is it /local..., or /use/local..., or /var, or=20
/etc.  There seem to be too many permutations.  My concern is that by not=20
imposing some discipline, one could end up with a similar situation for=20
library hierarchies.

This should not be taken as an objection to your proposal, but rather a=20
suggestion to not try and deploy it without a well considered default=20
hierarchy, which in the vast majority of cases would become the de-facto=20
global hierarchy.

> > Another thing that worries me a little is the apparent
> > complexity of the
> > scheme you proposed.  I think a clear and primary goal should
> > be to make it
> > easy to install, compile and use any software library from any
> > source.  Anything less would, I think, negatively impact
> > take-up of Haskell
> > 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.

That bit sounds good to me.

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

Versioning seems to be a notoriously difficult problem to get right for all=
=20
uses.  But I guess "80/20" is of real value.   (Thinks... can we use=20
Haskell expressions for version dependencies?)

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

That sounds good, though I suppose that's really an orthogonal issue.


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

<aside>
This reminds me of a favourite comment of my old Mathematical Analysis=20
tutor:  "If something is obvious, then either it can be proven in three=20
lines or it's an assumption".
</aside>

>Compare this with obtaining unique module names
>      currently: it's an ad-hoc and unsatisfactory scheme.
>
>    - module names within the library source code will be shorter.

I can appreciate this, but by way of exploration, I might suggest that it's=
=20
not so important that the module names in source code are shorter, but that=
=20
the qualified forms used within the body of code are shorter.  That is,=20
long module names in a module introduction (e.g. in import  statements) are=
=20
relatively benign, as long as names used in the body of code can be=20
suitably shortened.

#g



------------
Graham Klyne          _________
GK@ninebynine.org  ___|_o_o_o_|_=AC
                    \____________/
(nb Helva)       ~~~~~~~~~~~~~~~~~~   @Kingston, River Thames