Exception handling rules

The typical structure of a TeleoR procedure is a linerisation of a sub-goal tree routed at the guard of the first rule. When called, the partially instantiated first rule guard is the goal of the call, and the partially instantiated guards of the later rules are sub-goals of the call goal. The leaf goals of this sub-goal tree represent initial states of the robotic agent's environment that might prevail when the procedure is invoked. They are handled by an action rule with a guard LG towards the end of the rule body with an action that will normally bring about an environment state in which some guard G of a higher rule will hold.

However, in some applications exception situations can occur at any time during the procedure call, usually entirely outside of the agent's control. An example is a possible collision that is signalled by a percept that another robot is close. The action of such a rule should ensure there is no collision and ultimately result in an environment state in which another robot is not perceived as close. That is, the goal the action response should achieve is often just the negation of the rule guard. The issue is where to place such exception rules.

One solution is to place them at the end of the normal rules. Such a TeleoR procedure body would then take the form

where G1,...,Gn are the guards detecting the "normal" environment states which have a sub-goal ordering rooted at the guard G1 and EG1,...,EGm are the guards of the exception rules. The Gi guards fall into normal sub-goal tree where a later guard will not hold, so a later rule will not fire, when an earlier guard holds, and that is exactly what we want to happen.

But with exception rules we need them to fire as soon as the exception is detected. It will not generally be the case that when an exception occurs that none to the normal guards G1,...,Gn holds. To give precedence to exception handling, we will have to augment the normal guards to explicitly rule out the possibility that an exception needs to be handled. In other words we would have to include the equivalent of the conjunction

as part of each Gi.

Further, EGm is typically the worst exception and EG1 is the least worst exception and it is usually the case that each EGi will explicitly include the conjunction of the negation of later exception rule guards.

In the 'logical' semantics of TeleoR rules each guard implicitly contains the conjunction of the negations of all earlier guards. In the example above we have had to explicitly add the conjunction of negations of exception rule guards and so, from a logical semantics point of view it would make more sense to put the exception rules first, even though their guards will not usually have a sub-goal relationship and the guard G1, giving the goal of each procedured call, will no longer be the guard of the first rule. For the same reason, when we put the exception rules first we would typically invert the order.

It could also be argued that from a readability point of view putting the exception rules first signals their importance. On the other hand, also from a readability point of view, the casual reader of such a procedure might not notice that the exception rules are special or that normal regression is not being followed.

Our solution is to bracket the exception rules using >>>, <<< chevron sequences (which are purely syntactic). The chrevons indicate that the rules inside the chevrons are special. They take priority over the normal sub-goal achieving rules but their guards are not sub-goals of the goal for which the procedure is invoked, and their actions are not required to 'achieve' the guard of a higher exception rule. Quite the contrary, their actions are intended to change the environment so that none of the exception guards will hold, allowing a return to the normal sub-goal regression using the rules below the <<<.

The revised procedure body would then have the form:

Now, G1,...,Gn do not now have to explicitly mention the negation of the exception rule guards.

The guard evaluation order for the exception rules is before-after as for the regression rules. So where there is more than one exception condition that needs to be handled, the rules will typically be ordered so that the most serious exception condition is handled by the guard EG1 of the first exception rule. Further, the guard EGi of an exception rule lower down the exception rule sequence will typically be a lesser exception condition, and the repair action RA1 of the first rule could be such that it normally brings about the lower exception rule guard EGi. So we could have an inverted sub-goal tree of exception rule guards with actions that are intended to descend the exception sub-goal structure of regression rule guards so that eventually a normal goal achieving following the <<< can be fired.