Libraries and hierarchies

Simon Marlow
Wed, 13 Aug 2003 16:49:13 +0100

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

Yes, that's a pretty good analogy.

> In principle, this sounds great, but a fret a little about=20
> the practical=20
> deployment.  I use Linux a little, but am not by any means a=20
> Unix/Linux=20
> expert, and I find that I get *very* confused by the difference in=20
> directory structures used by different software packages=20
> and/or operating=20
> system distributions  (er, is it /local..., or /use/local...,=20
> or /var, or=20
> /etc.  There seem to be too many permutations.  My concern is=20
> that by not=20
> imposing some discipline, one could end up with a similar=20
> situation for=20
> library hierarchies.
> This should not be taken as an objection to your proposal,=20
> 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=20
> the de-facto global hierarchy.

This is exactly what I expect to happen; we would continue to
argue^H^H^H^H^Hdiscuss the layout of the hierarchy on, and maintain the hierarchy layout guidelines
somewhere on the web (perhaps the Wiki).  The layout would become an
agreement between library writers, rather than part of the language.

At some point we might want to standardise some of the hierarchical
libraries in a Haskell 98 Addendum, at which point those module names
would be fixed (at least for compilers which claimed to implement the