package mounting

Frederik Eaton frederik at a5.repetae.net
Fri Jun 24 11:21:48 EDT 2005


(By the way, sorry about cross-posting again. People have already
replied to just 'haskell@' and just 'libraries@' but I'll try to stick
to 'libraries@' after this since it seems that some users' mail
clients show them two copies otherwise)

> This idea has been raised before, but it was a while back, and we called
> it "grafting".  Here's the start of the thread, which went on for quite
> some time:
> 
>   http://www.haskell.org/pipermail/libraries/2003-August/001310.html

Actually it looks like that is slightly different from my idea,
perhaps I should have expounded a bit more in my original post.
Correct me if I'm wrong, but in my proposal:

- grafting/mounting would be done per compilation unit. In yours it
seems it would be done per (user, system).

- configuration of graft/mount points would be done at compile time,
zero or one times per package import option. In yours it would be at
package install time.

I think my proposal is better. In it there would be no cross-system
compatibility issues: since each program would specify where its
imported packages get mounted itself, you could write a Haskell
program on one system and be assured that someone else could use it on
another system without problems. I think this is a rather important
property and we shouldn't allow it to be broken - a warning that, as
you say, "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" is quite insufficient in my opinion! Plus, I think
the ability to remount packages at non-standard locations is an
important one, but for the above reason your proposal makes it too
dangerous and therefore unusable in practice.

Our proposals agree on this point:

> The implementation must obey the following rule:
>     When compiling a module belonging to a package, that package
>     is temporarily grafted into the root of the module hierarchy.

It was kind of "implicit" in my proposal though.

I think the "alternative design" which is mentioned in your proposal
is interesting:

> Alternative design: modules in the current package could be specified
> explicitly, perhaps by prefixing them with '.'.  This would avoid the
> possibility of overlap between the current package and the global
> hierarchy, at the expense of having to add lots of extra '.'s.

I think that might be a useful feature. Obviously one could introduce
the '.' syntax and still allow the present sytax to be used for
backward compatibility.

Frederik

-- 
http://ofb.net/~frederik/


More information about the Libraries mailing list