Version Numbers

[Rainer Blome]

Faré, you wrote:
> 1) to express extensions and restrictions of object specifications.
>   (i.e. object a++ is an extension to object a)
> 2) to check for dependencies between objects (i.e. are objects a and b
>   actually different versions of a same package; is there some object c
>   that supercedes both of them at lower cost than having them both ?)
> [...]
> * 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 exactly the objects' semantics (its specifications),
>  its dependencies (other modules it needs to run), its recent history (i.e.
>  how it was obtained from a previous version and/or user interaction).

This seems to ambitious to me for now.  We want to build a system that
enables us to work on this high a level, but not immediately so.  I believe
the system should be layered.

The lower layer handles identification (numbering, naming) of versions
only and doesn't deal with the meaning of ids other than lineage.  The id
is kept small and won't blow up the size of medium-sized objects (e.g
methods).  This is what we need immediately.

The next layer(s) handles modules and the semantic relationships you
mentioned.  That layer should be implemented on top of HLL (as a module!? ;-).
For the time being we'll emulate that layer by thinking.


> * there is a user-controlled programmable inference system to track
>  the above dependencies between objects.
> [...]
>    What are good ways to (semi-automatically) group objects into packages
> of closely-related objects that do not interact as much at all
> with external objects ? What information must we ask the programmer, must
> we compute when compiling, must we gather while running, must we forget
> when freezing, etc ?

This reference deals with that topic:
<a href="http://self.stanford.edu/papers/gold.html"> "Sifting out the Gold"</a>


> * there is a ("intelligently") locally cached global (yes, really) database
>  of known  dependencies, that serves as a basis to the above inference system.
> [...]
>    This database is really a world-wide knowledge database.
That is *way* beyond Tunes 1.0.

> * there is some global unique addressing scheme used by the above database.
This is essential for all (a lot) of Tunes.


Rainer