Graham Klyne writes:

Ummm... OK, let's see if I follow, by example. It sounds a bit like a Unix file tree, where new filesystems can be grafted (mounted) at any point in the tree. I could imagine a Web-based filesystem in which a URI (which is, by definition, globally unique) can be mounted at any point in the file tree, and then 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 the practical deployment. I use Linux a little, but am not by any means a Unix/Linux expert, and I find that I get *very* confused by the difference in directory structures used by different software packages and/or operating system distributions (er, is it /local..., or /use/local..., or /var, or /etc. There seem to be too many permutations. My concern is that by not imposing some discipline, one could end up with a similar situation for library hierarchies.

This should not be taken as an objection to your proposal, but rather a suggestion to not try and deploy it without a well considered default hierarchy, which in the vast majority of cases would become 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 libraries@haskell.org, 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 addendum). Cheers, Simon