4.10.6 Action Definitions

An action definition consists of a sequence of rules of the form

Head :: Commit ~> Actions

where Head and Commit are the same as for relation rules and Actions is a an action sequence.

The :: Commit part of the rule is optional. The heads of each rule of an action have the same functor and arity.

The semantics of action definitions is the nearly the same as for relation definitions. The first difference is that Actions is a sequence of actions rather than a sequence of relations. The second difference is that backtracking is only local to the Commit. So that, even if the rules don’t have a Commit, backtracking will not try other rules.

Also, for each action definition, the compiler adds a catchall rule to the end of the defined rules which raises an exception. This means that, if a call to an action does not match any of the defined rules then an exception will be raised as opposed to failure occurring (as would happen in a relation definition). This is also true for builtin actions. All builtin actions are also deterministic (i.e. no choice points are created by calling a builtin action). A consequence of this is that user defined actions also have this property. That is all actions are deterministic and all actions raise an exception rather than failing if no matches are found.

Below is an action definition example from examples/introduction/qlexamples.qlg.

act birthday(!human)
birthday(P) :: person(P, _, A) & Z = A+1 & type(Z, age) ~> 
        forget_remember([age_of(P, A)], [age_of(P, Z)])
birthday(P) ~>
    write_list([P,' has no recorded age or already has max age'])

The guard of the first rule looks up the age of the person and also type checks Z - this is necessary as A+1 is not guaranteed to be of type age. This guard could fail, either because P is not in the belief store as a person or because P was 110 old and 111 is not of type age. If the second rule was not present, then this situation would cause a no_matching_action_rule exception to be raised.


On This Site