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