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 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? 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.
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 uses. But I guess "80/20" is of real value. (Thinks... can we use 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 tutor: "If something is obvious, then either it can be proven in three 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 not so important that the module names in source code are shorter, but that the qualified forms used within the body of code are shorter. That is, long module names in a module introduction (e.g. in import statements) are relatively benign, as long as names used in the body of code can be suitably shortened. #g ------------ Graham Klyne _________ GK@ninebynine.org ___|_o_o_o_|_¬ \____________/ (nb Helva) ~~~~~~~~~~~~~~~~~~ @Kingston, River Thames