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