The first of the above forms is a special case of the second where RuleGuard is true. A consequence of this is that all the rules are committed rules, i.e. function calls are deterministic. This is one of the main differences between function rules and relation rules - relations are non-deterministic. Another difference is that relation calls can fail whereas functions are not allowed to fail. Instead, if no rules match the function call then a no_matching_function_rule exception it raised. This is flagging that we are outside of the domain of the function.
Consider the following definition of the factorial function.
The type check call is required as the type checker deduces the type of N1 is int after the subtraction. Can we avoid this type check call? We could if we change to the code below.
However, we can give fact2 a negative number and this will lead to infinite computation. In an attempt to fix this we could add a guard to the second rule as follows.
Now the problem is that if we give this function a negative number we will raise a no_matching_function_rule exception. This is because fact3 is not a total function on its domain (int).
For the next example we consider converting between lists and ordered trees. Note that this code does not produce balanced trees.
Recall that <> is the list concatenation function. We use the generic term ordering @<.
We finish this section by giving three examples of higher order functions - i.e. functions that take fuctions or relations as arguments. The example file contains several more such examples.
You will note that in each example we have a compound term with a variable functor. The type check allows this if the variable functor is known to be a ground code type as is the case in these examples.
In the second and third examples the head of the rule is a compound term whose function is itself a compound term. The third function definition is unusual - it is declared as a function but the rule is a relation rule. This is because curryR(Rel)(X) is a one argument relation and so when we apply this to its argument we get a relation call and so we need a relation rule.
Please note the complex type declaration for curryR. This intersection type allows different modes for the second argument that is reflected in the modes of the resulting relation. This maximizes the flexibility of use of this function.
