Guards †

Rules with a Guard †

Guards specify applicability conditions of rewrite rules. The syntax of a rule with a guard is:

$\textit{Head}\ \texttt{:-}\ \textit{Guard}\ \texttt{|}\ \textit{Body}$

where $\textit{Guard}$ is a multiset of type constraints of the form $c(\texttt{\}p_1, \dots, \texttt{\}p_n)$.

Type constraints constrains the shapes of processes (or the names of unary atoms) received by the process contexts $\texttt{\}p_1, \dots, \texttt{\}p_n$. The type constraint name $c$ is drawn from a built-in set and specifies which kind of constraints is imposed.

A constraint of the form uniq($\texttt{\}p_1, \dots, \texttt{\}p_n$) is also allowed. This is a control structure rather than a type constraint and used to avoid infinite rule application (see below).

Examples †

Here is an example rule with guard:

waitint(X), $p[X] :- int($p) | ok.

This can be abbreviated to

waitint($p) :- int($p) | ok.

and can be thought of representing the following infinite number of rules:

waitint(0)  :- ok.   waitint(1)  :- ok.    waitint(-1) :- ok.
waitint(2)  :- ok.   waitint(-2) :- ok.   ...

The following are examples of some type constraints that can be written in Guard:

• int($p) ... specifies that$p must be an integer atom.
• 4($p) ... specifies that$p must be a unary integer atom of value 4 (i.e., 4(X)).
• $p <$q ... specifies that $p and$q are integer atoms such that the value of $p is less than that of$q.

The same abbreviation scheme as defined for atoms applies to type constraints when a process context name $pk occurs exactly twice in the rule. For example, p($n) :- $n>$z, 0($z) | ok can be abbreviated to: p($n) :- $n>0 | ok A process context constrained in Guard is said to be a typed process context. Guard Library † The following type constraints can be used in guards. The + (input) sign preceding a process context name means that the name should appear in the head, while the - (output) sign means that the name should not appear in the head. Type checking † int(+$i)
check if $i[X] is an integer. float(+$f)
check if $f[X] is a floating-point number. unary(+$u)
check if $u[X] is a unary atom. Note that int and float are subtypes of unary. ground(+$g)
check if $g[X1,...,Xn] (n>0) is a connected graph whose free links are exactly X1,...,Xn. Note that unary is a subtype of ground. Comparison † '='(+$u,+$v) check if$u[X1,...,Xn] and $v[Y1,...,Yn] are connected graphs with the same structure. '\='(+$u,+$v) check if$u[X1,...,Xn] and $v[Y1,...,Ym] are connected graphs with different structures. '=='(+$u,+$v) check if$u[X] and $v[Y] are unary atoms with the same name. '\=='(+$u,+$v) check if$u[X] and $v[Y] are unary atoms with different names (if either of them are not unary, the check fails.) '<.'(+$float,+$float) float comparison; also: '>.', '=<.', '>=.', '=:=.', '=\=.'. '<'(+$int,+$int) integer comparison; also: '>', '=<', '>=', '=:=', '=\='. Assignment † '='(+$u,-$v) make sure that$u[X] and $v[Y] are unary atoms with the same name. '='(-$u,+$v) same as above. int(+$float,-$int) cast to int. float(+$int,-$float) cast to float. 345(-$int)
defined for every integer (not only with 345).
'-3.14'(-$float) defined for every float. '+'(+$int,+$int,-$int)
integer operation; also: '-', '*', '/', mod.
'+.'(+$float,+$float,-$float) float operation; also: '-.', '*.', '/.'. Avoiding Infinite Rule Application † A constraint of the form uniq($p1, ..., $pn) succeeds if each$pk is a ground structure (connected graph with exactly one free link; see below) and the rule has not been applied to the tuple $p1, ...,$pn before.

As a special case of n=0, uniq succeeds if the rule in question has not been used before. The uniq() test is a general tool for avoiding infinite application of rules whose right-hand side is a super(multi)set of the left-hand side.

uniq(+$g1,...,+$gn)
uniqueness constraint; checks if the rule has not been applied to the tuple $g1[X1], ...,$gn[Xn] (n>=0).

Last-modified: 2019-05-02 (Thu) 12:06:54 (263d)