#458 New kind or RELATION: "SEQUENCE"

[Rieks]

In order to make the meatgrinder useable in combination with the (new) frontend, we must find an efficient way of dealing with relations whose pairs are sequenced.

The 'pairView' array (found in Generics.PHP) exemplifies the issue. This array is an attribute for rules. Its elements are 'Segments', each of which is either a piece of text, or (MySQL-code for) an expression that is to be evaluated runtime (the result of which is to be output). In their proper sequence, the segments ensure the proper displaying of a VIOLATION message that contains texts and violation-specific data. In order to model this, we could use:

RELATION pairView[Rule,Segment] [INJ,SUR]

but this does not cater for the fact that Segments are to be sequenced. The current way to resolve this is (at a minimum!):
- to define a RELATION successor[Segment*Segment] [ASY,IRF]
- to define a RULE pairView~;pairView |- I \/ successor* \/ (successor~)*
Note that the only way for catering for '*' consists of defining another 2 relations, the rule that defines '*' and an ExecEngine procedure (Warshall) that recomputes the entire '*' relation any time there is a change.
All this is too cumbersome to be a realistic, or efficient, soultion.

In order to use such constructs efficiently in a (database)application such as, but not exclusively, the frontend of prototypes, we need functions such as:
- getFirstTargetAtom($relation,$srcConcept,$srcAtom,$tgtConcept)
- getNextTargetAtom($relation,$srcConcept,$srcAtom,$tgtConcept,$tgtAtom)
each of which returns the requested target Atom, or an error if either there is none, or the relation is not sequenced.
(Similar functions such as getLastTargetAtom and getPreviousTargetAtom are nice, too)

I would like to see suggestions for efficiently doing this, and have at least one implemented.

The feature request I propose is
[1] to add a relation property 'SEQ' (similar to UNI, TOT etc.) that specifies that a relation is a sequence.
[2] determine the seqeuence by the order in which the relation is populated (both for populations specified in ADL and runtime (de)populations).
This means that following 'rules' are maintained (not necessarily in the specified order):
- the pair that populates an empty relation is the first (and the last) pair of the sequence;
- a pair that populates a non-empty relation does the following (in the sequence as specified)
- it marks the last pair of the sequence as its predecessor;
- it marks itself as the successor of its predecessor;
- it becomes the last pair of the sequence;
- a pair that is removed from a relation ensures (in the sequence as specified) that
- if it is the only pair (i.e. the first pair and the last pair) of the sequence, it NULLifies the first and last pair of the sequence;
- if it is the first pair of the sequence, its successor (which exists!) becomes the first pair AND the predecessor of this successor is NULLified;
- if it is the last pair of the sequence, its predecessor (which exists!) becomes the last pair AND the successor of this predecessor is NULLified;
- if it is neither the first nor the last pair of the sequence, then its successor and its predecessor (which exist!) become their mutual succor and predecessor respectively.
[3] to add the earlier mentioned functions (getFirstTargetAtom etc.)