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(a)ninebynine.org ___|_o_o_o_|_¬
\____________/
(nb Helva) ~~~~~~~~~~~~~~~~~~ @Kingston, River Thames
