[Next] [Up] [Previous]

Appendix: Production Rules

POP-11 has a production system called PRODSYS, with rules of the form

 
rule <name/number> [ <condition> ] ;

   		 <action> ;

   		 <action> ;

   		 ...

endrule;

Their appearance is similar to those we presented earlier in our more informal notation. Here are two of the earlier rules, rewritten in PRODSYS form:

 
rule 31 [birdcage is open] [tweetie is in birdcage]

   		 [sylvester is in room];

   		 remove([birdcage is open]);

   		 add([birdcage is closed]);

endrule;

rule get_drink [user inserts coin];

   		 vars response;

   		 [Would you like tea or coffee?] =>>

   		 readline() -> response;

   		 remove([user inserts coins]);

   		 add([user wants ^^response]);

endrule;

Like a POP-11 procedure definition, a rule has a header line, which determines the circumstances in which it will be used, followed by a body containing some POP-11 code specifying what is to be done when the rule is invoked. Also, like a POP-11 procedure, it has a pair of terms -- rule and endrule -- which mark the beginning and end of the rule. The header line represents the condition part of the rule, and the commands between the header line and endrule represent the actions to be carried out if the rule is fired. Working memory is the standard POP-11 database, and the patterns in the condition are matched, using the standard POP-11 matcher, against items in the database. rule 31, for example, will be available for use if there are three items in the database which match:

[birdcage is open]
[tweetie is in birdcage]
[sylvester is in room]

PRODSYS uses a very simple conflict resolution strategy: rules are tried one by one in the order in which they were loaded, i.e., reading from the beginning to the end of the rulebase. This means that the same rule could be used on more than one occasion. If the built-in variable repeating is set to false, however, the system will not trigger the same rule on the same database items twice.

So far, all the rules we have seen in this appendix contain completely specified conditions and actions; we can, however, use variables to make the rules more general. Consider rule 7:

 
rule 7 [take umbrella] [sun shining];

    		 remove([take umbrella]);

    		 add([wear sunglasses]);

endrule;

It says in effect that if the sun is shining and you are carrying an umbrella, put it down and put on your sunglasses. Suppose we generalize the rule to say that, whatever you are carrying, if the sun is shining, all you need to take with you is a bucket and spade:

 
rule 4 [take ??x][sun shining];

    		 remove([take ^^x]);

    		 add([take bucket and spade]);

endrule;

Given the database

[[take umbrella] [sun shining]]

rule 4 will fire, changing the database to

[[take bucket and spade] [sun shining]]

What will happen next? Unless the control variable repeating is set to <false>, rule 4 will be triggered and fired again, since the pattern [take ??x] will still match the fact [take bucket and spade].

Consequently, the same rule will continue firing forever, unless the program is interrupted. The moral is that you should be cautious in the design of your rulebase (if using variables in your rules, it is wise to avoid, if possible, an action whose result might be matched against a condition in the same rule). repeating should be set to <false> if there is a risk of the same rule being fired repeatedly in a never-ending cycle.

• Using a Production System in the Automated Tourist Guide

[Next] [Up] [Previous]