Top
Type Conversion
Constraints
French
German
Italian
Spanish
Portuguese
Japanese
Korean
Chinese
When a variable of one mode is given in a position where a variable of another mode is expected, mode coercion goes on in much the same way as type coercion does.
There are two basic places in which mode coercion happens: in identity formulas and in predicate calls. In the descriptions that follow, we assume that all necessary type conversion has already taken place.
In processing the identity formula a = b, the action actually performed depends on the modes of the terms a and b.
For the purposes of the following table, we can consider output variables after their first assignment as input variables.
Any full-value term (any term made up only of constant terms, input variables, initialized output variables, initialized
input/output variables, and symbolic variables whose values are fixed as full-value terms) can also be considered an input variable.
- a input, b input: a and b are compared.
- a input, b output: at compile time, b is made to refer to the same value (in memory) as a.
- a input, b symbolic: if b has a value, it is compared with a; otherwise, b gets the value of a if compatible with the constraints on b.
- a input, b input/output: a and b are compared.
- a output, b output: b is backtracked out if possible, and the values are assigned to a.
- a output, b symbolic: if b has a value, it is assigned to a; otherwise, it is backtracked out if possible, and the values are assigned to a.
- a output, b input/output: a is assigned a copy of the value of b.
- a symbolic, b symbolic: an equality constraint is put between the two variables.
- a symbolic, b input/output: if a has a value, it is compared with b; otherwise, a gets a copy of the value of b if compatible with the constraints on a.
- a input/output, b input/output: a and b are compared.
The operation of "backtracking out" a variable a is possible when the type of a has a small finite number of elements (i.e., an enumerated type, a subrange type with fixed upper and lower bounds, or a finite array type etc,); or when a is a symbolic variable of
some other integral type (L, I, or a non-fixed subrange type) which is constrained to be in a small finite range.
If the system attempts to backtrack out a variable and fails, it raises the "too many backtracks" run-time error.
We can illustrate the mode coercion actions associated with predicate calls by a simple example. We have a predicate declared by
class P(x mode T) iff ...
where class is pred, proc, or subr, as appropriate, and mode is the mode of the parameter x. Given
a call to this predicate, P(y), what action is actually performed by the call?
Mode coercion on predicate calls table:
Mode of x (parameter) |
Mode of y (parameter) |
Action performed |
input |
input |
P(y) |
input |
output |
z :> T & z = y & P(z) |
input |
symbolic |
z :> T & z = y & P(z) |
input |
i/o |
z :> T & z = y & P(z) |
output |
input |
z :> T& P(z) & y = z |
output |
output |
P(y) |
output |
symbolic |
z :> T & P(z) & y = z |
output |
i/o |
z :> T & P(z) & y := z |
symbolic |
input |
z :: T & z = y & P(z) |
symbolic |
output |
z :: T & P(z) & y = z |
symbolic |
symbolic |
P(y) |
symbolic |
i/o |
z :: T& z = y & P(z) |
i/o |
input |
z :. T & z = y & P(z) |
i/o |
output |
z :. T & z := y & P(z) |
i/o |
symbolic |
z :. & z := y & P(z) |
i/o |
i/o |
P(y) |
Mode coercion on predicate table summarizes these actions. Usually, if the modes do not agree an auxiliary variable of the correct mode is
implicitly declared. Most of the work of mode coercion is then passed off to the mechanism for resolving identity formulas
(see previous section). The identity formula is computed either before or after the predicate call with the auxiliary variable, as appropriate.
Top
Type Conversion
Constraints