- List of Backups
- View the diff.
- View the diff current.
- View the source.
- Go to Guards.
- 1 (2004-02-01 (Sun) 13:13:23)
- 2 (2004-02-02 (Mon) 12:52:33)
- 3 (2004-04-06 (Tue) 11:45:47)
- 4 (2004-04-21 (Wed) 13:48:35)
- 5 (2004-10-15 (Fri) 10:59:26)
- 6 (2004-10-22 (Fri) 09:52:20)
*7 (2006-01-08 (Sun) 15:18:09)*- 8 (2006-03-14 (Tue) 14:33:50)
- 9 (2006-11-02 (Thu) 10:36:50)
- 10 (2006-11-02 (Thu) 10:36:50)
- 11 (2010-06-13 (Sun) 15:51:59)
- 12 (2015-05-17 (Sun) 20:34:13)
- 13 (2015-05-18 (Mon) 21:07:14)
- 14 (2017-03-02 (Thu) 03:32:49)
- 15 (2017-03-02 (Thu) 07:49:19)
- 16 (2019-04-29 (Mon) 10:31:19)
- 17 (2019-04-29 (Mon) 16:49:44)

The full syntax of a rule is:

Head:- [Guard| ]Body

where *Guard* is a multiset of **type constraints** of the form:
&math(p(\$p_1,\ldots,\$p_n));.

Type constraints put constraints on the shapes of processes
(or the names of unary atoms)
with which the process contexts specified in its arguments can match.
The **type constraint name** &math(p); is drawn from a built-in set and specifies which kind of constraints is imposed.

Here is an example rule with guard:

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

This rule can be thought of as an abbreviation of the following infinite number of rules:

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

The following list contains 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.
- $r = $p +. $q --- specifies that $p, $q, and $r are floating point number atoms such that the sum of the values of $p and $q is equal to the value of $r.

Each type constraint name (such as int or <) has its own mode of usage that specifies which of its arguments are input arguments. The effect of the constraint specified by a type constraint is enabled only after the shapes (or values) of its input arguments are all determined. For example, $r = $p + $q proceeds only when $p and $q are determined.

The same abbreviation scheme as defined for atoms applies to type constraints when a process context name &math(\$p_i); 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 name $p constrained in *Guard*
is said to be **typed** in that rule.
As a syntactic sugar,
typed process context names can be written as link names.
For inscance, the above example can be written as:

waitint(X) :- int(X) | ok.

Currently, the following type constraints can be written in the guard. The + specifies an input argument.

'='(+U1,-U2) - make sure that U1 and U2 are (connected to) unary atoms with the same name '='(-U1,+U2) - same as above '=='(+U1,+U2) - check if U1 and U2 are (connected to) unary atoms with the same name unary(+U) - check if U is (connected to) a unary atom ground(+G) - check if G is (connected to) a connected graph with exactly one free link (which is G) int(+I) - check if I is (connected to) an integer float(+F) - check if F is (connected to) a float int(+Float,-Int) - cast float(+Int,-Float) - cast 345(-Int) - defined for every integer (not only with 345) '-3.14'(-Float) - defined for every float '<'(+Int,+Int) - integer comparison; also: > =< >= =:= =\= '+'(+Int,+Int,-Int) - integer operation; also: - * / mod '<.'(+Float,+Float) - float comparison; also: >. =<. >=. =:=. =\=. '+.'(+Float,+Float,-Float) - float operation; also: -. *. /.