Version Numbers

[Rainer Blome]

Jecel, you wrote that the "grouping" in Ole's and David's paper was
different from what we are talking about here, that they were just trying
to recreate maps (classes) at the Self level.  Do you really think they'd
write a paper about a task that trivial?  Indeed, they use that information
to allow conclusions about groups of objects, but generating it is only the
first step of five.

You omitted the central sentence from your quote of my message:
> * there is a user-controlled programmable inference system to track
>  the above dependencies between objects.

By "above dependencies" I referred to what Faré said in his message:
> * each object in a package points to a list of objects (possibly axioms of the
>  system, possibly objects from the same package, possibly external objects),
>  that define the object's [...] dependencies (other modules it needs to run)

In another message you said: [...] there should be some unit whose objects
> are copied while the others are not. Stuffing "the whole world" into a
> floppy is not very practical.

Exactly.  In the mentioned paper, an implementation of a system is
described that uses an inference process to extract from the Self world all
the objects needed to perform a specific task (respond to a message send).
(Actually, they did a little more than that: the objects were even stripped
of unneeded slots.)  In the abstract they say: "The extracted application
runs in a tenth (of) the space of the original environment."

Although they used their system on application startup messages (like
"benchmark quicksort start", it may as well be used on lower levels.  What
counts is that the resulting set of objects is independent of the rest of
the system (with respect to that particular message) and may therefore be
viewed as a module.

Finding dependencies or recording them or automatically creating/bounding
modules was not the authors' main concern.  But that information may easily
(I believe) be collected during the marking phases (this might even be a
way to do garbage collection?).  When modules (packages) are introduced, the
extractor will sometimes cross boundaries between modules when following a
potential send.  When not extracting an application but merely deducing
dependencies, that'd be the time to have the system record an
inter-module-dependency.

The central step dealing with dependencies in their system is called type
inference.  The corresponding reference is (must be s.th. like):
<a href="http://self.stanford.edu/papers/ecoop93a.ps.Z"> Type Inference
of Self: Analysis of Objects with Dynamic and Multiple Inheritance </a>
I have not bothered reading that so far coz I thought it'd deal with
run-time type inference only.  Maybe I'll get to read it now.

	Rainer