Version Numbers

[Francois-Rene Rideau]

>> ... worth wasting time worrying about this?
> Sure!
> Again, if we had what we wanted (i.e. an OO system), it'd be trivial:
Yes, yes, yes. But still, there are implementation problems about that:
the version control system should allow:
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 ?)
3) to have objects as small as possible, i.e. not having to move the whole
  version and hierarchy information if every single object
4) to have efficient way to store and/or compute all the above information.


> Multi-user access will surely complicate things, but that seems inevitable
> to me.
Well, "as soon as" there is a version graph, and not just a version line,
multi-user access becomes easy. That's what it was meant for, isn't it ?

I agree version control should be implemented deep into the module system.
Here is how I see things:

* objects are distributed in packages.
* 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).
* there is a user-controlled programmable inference system to track
 the above dependencies between objects.
* there is a ("intelligently") locally cached global (yes, really) database
 of known  dependencies, that serves as a basis to the above inference system.
* there is some global unique addressing scheme used by the above database.

   This database is really a world-wide knowledge database.
To achieve any efficiency, it must be (dynamically ?) clustered.
And this is yet another problem:
   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 ?
   Actually, this is *the* problem that arises when we want efficient
distributed computing...

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://acacia.ens.fr:8080/home/rideau/Tunes/"