Packages
Simon Peyton-Jones
simonpj at microsoft.com
Mon Sep 15 10:17:00 EDT 2003
| > Meta-data that describes the package
| ...
| > - Dependencies, expressed as a set of triples
| > (package identifier, version range, grafting location)
|
| This raises an issue.
|
| Someone releases package foo. I release a package bar that uses foo,
| where foo is grafted at A.B.Foo. Someone else wants to use bar, but
they
| have foo grafted at C.D.Foo, because they also have a completely
| unrelated otherfoo grafted at A.B.Foo. Does their use of bar force foo
| to be grafted at the same place I grafted it at?
No, it doesn't, and that should be made clearer in the proposal.
Suppose package P imports packages Q, R. Then the grafting locations
for Q,R specified in P's meta-data are only needed to make sense of the
*source code* of P. to compile P from source you must graft Q, R at the
specified places. But, having compiled it (or having downloaded a
compiled version) it's not necessary to even know of where P expects Q
and R to show up.
For an interpreter like Hugs, matters are a bit more complicated, I
guess. When loading a module M from P, Hugs would have to remember
where Q and R show up in the module hierarchy. Yet that seems an
inevitable consequence of not fixing a single global location for every
module at the moment of its birth.
Simon
More information about the Libraries
mailing list