Re:

[Tim Klinger <klinger@xxxxxxxxxx>]

>In Indigo, most of objects inherits the Relying_object class (Objet_pose
>in french). This class has the slot 'intersections' which is the set
>of intersections on which the objet relies. 
>
>The slot 'intersections' of a relying object is a reference to the relying 
>object that is very useful in Indigo. 
>
>For incremental data structure, the Relying_object class has the 'track' slot
>that is the set of intersections from which the existence of the object
>depends. When a move is played ouside the track of an object, the object
>remains and, conversely, when a move is played inside the track then the
>object
>is deleted (or saved in a cache).
>
>Bruno

We have something sort of similar.  Objects can 'depend' on other objects
causing them to be alerted when the dependency changes.  They can then
alert any objects that depend on them, recursively.  Using this as the
basic structure we built a truth maintenance system (TMS) which monitors
changes in board occupancy, liberties, and other terms of interest.  Any
object that needs to can request a constraint that it can 'depend' on.  For
instance, our pattern matcher works incrementally this way.  When a pattern
matches, a constraint of the form: color(p1) == c1 and color(p2) == c2 etc.
is constructed and registered with the TMS.  If later the constraint is
violated the TMS sends an alert to the pattern match letting it know that
it is no longer valid.  The match will then send an alert to a database to
let it know that any assertions about the state made by the match should
now be revoked.

Tim