RE: Libraries and hierarchies

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.
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. - 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 currently: it's an ad-hoc and unsatisfactory scheme. - module names within the library source code will be shorter. Cheers, Simon
participants (1)
-
Simon Marlow