The names of predicates (and corresponding object fields) must be globally unique within one GRS. This means that a predicate can be used only with one single type in a GRS. Field names may occur in different objects, however, then only one of them may be refered to in a GRS. Otherwise the typecheck-algorithm of may deliver unexpected results.
It is currently not possible to define target code global variables for entire GRS, nor for a -module. It is only possible for a single rule group. Thus passing variables around between rule groups is not easy. One trick is to include additional variables in the parameter list of the GRS. Then they are known globally.
Note that currently it is very simple to add multiple edges between the same nodes in EGRAPHs. Then the result of the generated routine may be unexpected.
Currently for non-recursive EARS no fixpoint evaluation is generated. This is only correct, if the computed predicates do not rely on each other. The rules are currently not sorted along their rule dependency graph. Be careful!
Note that the variables which are defined in patterns are not allowed to be used for further navigation, only for the use in target predicates, e.g. to test attributes. Also it is not allowed to use constant patterns. Constant comparisons are only allowed in equality tests (section 3.6.3).
Currently there is no automatic stratification of rules in rule groups.
The code generated for order loops may be buggy, because the implementation of the order algorithm is tricky.