The type of rules that you've seen so far illustrates simple matching of patterns to facts. In this tutorial, you'll learn very powerful ways to match and manipulate facts.

Just as with other programming languages, CLIPS has variables to store values. Unlike a fact, which is static or unchanging, the contents of a variable are dynamic as the values assigned to it change. In contrast, once a fact is asserted, retracting and asserting a new fact with the changed fields can only modify its fields.

The name of a variable, or variable identifier, is always written by a question mark followed by a symbol that is the name of the variable. The general format is

Global variables, have a slightly different syntax. Just as in other programming languages, variable names should be meaningful for good style. Some examples of valid variable names follow.

Before a variable can be used, it should be assigned a value. As an example of a case where a value is not assigned, try to enter the following and CLIPS will respond with the error message shown.

CLIPS> (clear)

CLIPS> (defrule test

=>

=>

CLIPS>

CLIPS gives an error message when it cannot find a value bound to ?x. The term bound means the assignment of a value to a variable. Only global variables are bound in all rules. All other variables are only bound within a rule. Before and after a rule fires, nonglobal variables are not bound and so CLIPS will give an error message if you try to query a nonbound variable.

One common use of variables is to match a value on the LHS and then assert this bound variable on the RHS. For example, enter

=>

Now assert (dog-sound woof), then (run) the program. Check the facts and you'll see that the rule has produced (sound-is woof) because the variable ?sound was bound to woof.

Of course, you also can use a variable more than once. For example, enter the following. Be sure to do a (reset) and assert (dog-sound woof) again.

=>

When the rule fires, it will produce (sound-is woof woof) since the variable ?sound is used twice.

Variables also are used commonly in printing output, as in

=>

Do a (reset), enter this rule, and assert the fact and then (run) to find out what the duck said. How would you modify the rule to put double quotes around quack in the output?

More than one variable may be used in a pattern, as the following example shows.

CLIPS> (clear)

CLIPS> (defrule whodunit

=>

CLIPS> (reset)

CLIPS> (assert (duckshoot Brian duck))

CLIPS> (run)

CLIPS> (assert (duckshoot duck Brian)

CLIPS> (run)

CLIPS> (assert (duckshoot duck) ) :Missing third field

CLIPS> (run)

Notice what a big difference the order of fields makes in determining who shot who. You can also see that the rule did not fire when the single-field fact (duck) was asserted. The rule was not activated because no field of the fact matched the second pattern constraint, ?who.

Retraction is very useful in expert systems and usually done on the RHS rather than at the top-level. Before a fact can be retracted, it must be specified to CLIPS. To retract a fact from a rule, the fact-address first must be bound to a variable on the LHS.

There is a big difference between binding a variable to the contents of a fact and binding a variable to the fact-address. In the examples that you've seen such as (dog-sound ?sound), a variable was bound to the value of a field. That is, ?sound was bound to woof. However, if you want to remove the fact whose contents are (dog-sound woof), you must first tell CLIPS the address of the fact to be retracted.

The fact-address is specified using the left arrow, "<-". To create this, just type a "<"symbol followed by a "-". As an example of fact retraction from a rule.

CLIPS> (clear)

CLIPS> (assert (bachelor Dopey))

CLIPS> (facts)

CLIPS> (defrule get-married

=>

CLIPS> (run)

CLIPS> (facts)

CLIPS>

Notice that the (printout) prints the fact-index of ?duck, <Fact-0>, since the left arrow bound the address of the fact to ?duck. Also, there is no fact (bachelor Dopey) because it has been retracted.

Variables can be used to pick up a fact value at the same time as an address, as shown in the following example. For convenience, a (deffacts) has also been defined.

CLIPS> (clear)

=>

(printout t ?name is now happily married" crlf)

(retract ?duck)) I

CLIPS> (deffacts good-prospects

CLIPS> (reset)

CLIPS> (run)

CLIPS>

Notice how the rule fired on all facts that matched the pattern (bachelor ?name).

Instead of binding a field value to a variable, the presence of a nonempty field can be detected alone using a wildcard. For example, suppose you're running a dating service for ducks, and a duckette asserts that she only dates ducks whose first name is Richard. Actually, two criteria are in this specification since there is an implication that the duck must have more than one name. So a plain (bachelor Richard) isn't adequate because there is only one name in the fact.

This type of situation, in which only part of the fact is specified, is very common and very important. To solve this problem, a wildcard can be used to fire the Richards.

The simplest form of wildcard is called a single-field wildcard and is shown by a question mark, "?". The "?" is also called a single-field constraint. A single-field wildcard stands for exactly one field, as shown following.

CLIPS> (clear)

CLIPS> (defrule dating-ducks

=>

CLIPS>

(deffacts duck

CLIPS> (reset)

CLIPS> (run)

Date Dopey

CLIPS>

The pattern includes a wildcard to indicate that Dopey's last name is not important. So long as the first name is Dopey, the rule will be satisfied and fire. Because the pattern has three fields of which one is a single-field wildcard, only facts of exactly three fields can satisfy it. In other words, only Dopeys with exactly two names can satisfy this duckette.

Suppose you want to specify Dopeys with exactly three names? All that you'd have to do is write a pattern like

or, if only persons with three names whose middle name was Dopey,

or, if only the last name was Dopey, as in the following:

Another interesting possibility occurs if Dopey must be the first name, but only those Dopeys with two or three names are acceptable. One way of solving this problem is to write two rules. For example

(defrule eligible

=>

(defrule eligible-three-names

=>

Enter and run this and you'll see that Dopeys with both two and three names are printed. Of course, if you don't want anonymous dates, you need to bind the Dopey names with a variable and print them out.

Rather than writing separate rules to handle each field, it's much easier to use the multifield wildcard. This is a dollar sign followed by a question mark, "$?" , and represents zero or more fields.

The two rules for dates can now be written in a single rule as follows.

CLIPS> (clear)

CLIPS> (defrule dating-ducks

=>

CLIPS> (deffacts duck

Wildcards have another important use because they can be attached to a symbolic field to create a variable such as ?x, $?x, ?name, or $?name. The variable can be a singlefleld variable or a multifield variable depending on whether a "?"or "$?" is used on the LHS. Note that on the RHS only a ?x is used, where the "x" can be any variable name. You can think of the "$" as a function whose argument is a single-field wildcard or a single-field variable and returns a multifield wildcard or a multifield variable, respectively.

As an example of a multifield variable, the following version of the rule also prints out the name field(s) of the matching fact because a variable is equated to the name field(s) that match:

CLIPS> (defrule dating-ducks

=>

(printout t "Date Dopey " ?name crlf))

CLIPS> (reset)

CLIPS> (run)

CLIPS>

As you can see, on the LHS, the multifield pattern is $?name but is ?name when used as a variable on the RHS. When you enter and run, you'll see the names of all eligible Dopeys. The multifield wildcard takes care of any number of fields. Also, notice that multifleld values are returned enclosed in parentheses.

Suppose you wanted a match of all ducks who had a Dopey somewhere in their name, not necessarily as their first name. The following version of the rule would match all facts with a Dopey in them and then print out the names:

CLIPS> (defrule dating-ducks

CLIPS> (reset)

CLIPS> (run)

CLIPS>

The pattern matches any names that have a Dopey anywhere in them.

Single- and multifield wildcards can be combined. For example, the pattern

means that the first and last names can be anything and that the name just prior to the last must be Dopey. This pattern also requires that the matching fact will have at least four fields, since the "$?" matches zero or more fields and all the others must match exactly four.

Variables used in patterns have an important and useful property, which can be stated as follows.

For example, in the rule below

(defrule bound

If there are some facts

then the rule can only be activated by the pair f-0, f-1, and the other pair f-2, f-3. That is, fact f-0 cannot match with f-3 because when ?num is bound to 0 in the first pattern, the value of ?num in the second pattern also must be 0. Likewise, when ?num is bound to 1 in the first pattern, the value of ?num in the second pattern must be 1. Notice that the rule will be activated twice by these four facts: one activation for the pair f-0. f-1, and the other activation for the pair f-2, f-3.

As a more practical example, enter the following rule. Notice that the same variable, ?name, is used in both patterns.

CLIPS> (clear)

CLIPS> (defrule ideal-duck-bachelor

=>

CLIPS> (deffacts duck-assets

CLIPS> (reset)

CLIPS> (run)

CLIPS>

When the program is run, the first pattern matches Dopey and Dorky since they both have big bills. The variable ?name is bound to each name. when CLIPS tries to match the second pattern of the rule, only the variable ?name which is bound to Dopey also satisfies the second pattern of (feet wide).