Typechecking

A rewrite specification in an EARS or GRS is checked against the data model in the following way (Figure 2.1).

  

Figure 2.1: Typechecking a rewrite rule against the data model. Predicates refer to field names (solid lines), variables to object types (dashed lines).

1.

for all predicates, lookup the predicate as a field in an object.

2.

determine the type of the field.

object type (pointer type)

(in the figure predicate1) Then the relation is one-valued. The containing object type of the predicate determines the type of the left variable of the predicate. The right type is the type of the field.

set functor type

(in the figure predicate2) Then the relation is multi-valued, and represented by a call to an embedded set functor. This means that the field consists of a set of neighbors of an object type (the parameter of the functor call). This parameter determines the type of the right variable of the predicate. The containing object type of the predicate determines the type of the left variable of the predicate.

list functor type

Same as previous case, except that the neighbor set is ordered.

graph functor type

(in the figure predicate4) Then the relation is a functor-created graph over two types. The first parameter makes up the type of the left variable, the second that of the right variable.

3.

When all types of variables for predicates have been determined, check whether these are compatible (equal or subtypes of each other).

uses the type information on variables and predicates to generate correct navigation and manipulation code. This code calls functions from the functor libraries (loop over neighbor sets, add edges, delete edges, delete nodes, add nodes, test existance of edges). The variable type information is also used to check whether the user has specified correct pattern matching.

Currently only supports a fixed set of functors, either from the CoSy functor library or from the sol-library which is shipped in the distribution.