CLIPS: an Open Source Expert System

A fact such as (duck) or (quack) is said to consist of a single field. A field is a placeholder (named or unnamed) that may have a value associated with it. As a simple analogy, you can think of a field as a picture frame. The frame can hold a picture, perhaps a picture of your pet duck (For those of you who are curious what a picture of a quack looks like, it could be (1) a photo of an oscilloscope trace of a duck saying quack, where the signal input comes from a microphone, or (2) for those of you who are more scientifically inclined, a Fast Fourier Transform of the quack signal, or (3) a TV-huckster selling a miracle cure for wrinkles, losing weight, etc.). Named placeholders are only used with deftemplates, described in more detail further on.

The (duck) fact has a single, unnamed placeholder for the value duck. This is an example of a single-field fact. A field is a placeholder for a value. As an analogy to fields, think of dishes (fields) for holding food (values).

The order of unnamed fields is significant.

Actually, it is good software engineering to start the fact with a relation that describes the fields. A well-constructed fact would be (hunter-game duck Brian) to imply that the first field is the hunter and the second field is the game.

A list is a group of items with no implied order. Saying that a list is ordered means that the position in the list is significant. A multifield is a sequence of fields, each of which may have a value. The examples of (duck Brian) and (Brian duck) are multifield facts.

If a field has no value, the special symbol nil, which means nothing may be used for an empty field as a placeholder. For example,

(duck nil)

would mean that the killer duck bagged no trophies today.

Note that the nil is necessary to indicate a placeholder, even if it has no value. For example, think of a field as analogous to a mailbox. There 's a big difference between an empty mailbox, and no mailbox at all. Without the nil, the fact becomes a single-field fact (duck). If a rule depends on two fields, it will not work with only one field, as you 'll see later.

There are a number of different types of fields available: float, integer, symbol, string, external-address, fact-address, instance-name and instance-address The type of each field is determined by the type of value stored in the field. In an unnamed field, the type is determined implicitly by what type you put in the field. In deftemplates, you can explicitly declare the type of value that a field can contain. The use of explicit types enforces the concepts of software engineering, which is a discipline of programming to produce quality software.

A symbol is one type of field that starts with a printable ASCII character and is followed optionally by zero or more printable characters. Fields are commonly delimited or bounded, by one or more spaces or parentheses. For example,

(duck-shot Brian Gary Rey)

However, this could be a legal deftemplate fact if shot is defined as the name of a field, while Brian Gary Rey are the values associated with the named field.

CLIPS is case-sensitive. Also, certain characters have special meaning to CLIPS.

" ( ) & | < ~ ; ? $

The &, |, and ~ may not be used as stand-alone symbols or as any part of a symbol.

Some characters act as delimiters by ending a symbol. The following characters act as delimiters for symbols.

• any non-printable ASCII character, including spaces, carriage returns, tabs, and linefeeds
• double quotes, "
• opening and closing parentheses, ()
• ampersand, &
• vertical bar, |
• less than, <. Note that this may be the first character of a symbol
• tilde, ~
• semicolon, ; indicates start of a comment, a carriage return ends it
• ? and $? may not begin a symbol but may be inside it

The semicolon acts as the start of a comment in CLIPS. If you try to assert a semicolon, CLIPS will think you 're entering a comment and wait for you to finish. If you accidentally enter a semicolon in top-level, just type in a closing parenthesis and carriage return. CLIPS will respond with an error message and the CLIPS prompt will reappear (This is one of the few approved occasions in life in which it 's necessary to do something wrong to get something right.)

The following are examples of symbols:

duck
duck1
duck_soup
duck-soup
duck1-1_soup-soup
d!?#%^

The correct way to put double quotes in a fact is with the backslash, \,

The second type of field is the string. A string must begin and end with double quotes. The double quotes are part of the field. Zero or more characters of any kind can appear between the double quotes. Some examples of strings

"duck"
"duck1"
"duck/soup"
"duck soup"
"duck soup is good!!!"

The third and fourth types of field are numeric fields. A field which represents a number can be either an integer or floating-point type field. A floating-point type is commonly referred to simply as a float.

All numbers in CLIPS are treated as long long integers or double-precision floats. Numbers without a decimal point are treated as integers unless they are outside integer range. The range is machine dependent on the number of bits, N.

Each fact must start with a symbol such as number, x, y, etc. Before CLIPS version 6.0, it was possible to enter only a number as a fact. However, now a symbol is required as the first field.

Also, certain reserved words used by CLIPS cannot be used as the first field, but may be used for other fields. For example, the reserved word not is used to indicate a negated pattern and may not be used as the first field of a fact.

Removing facts from the fact-list is called retraction and is done with the retract command. To retract a fact, you must specify the fact index of the fact as the argument of retract. For example, after setting up your fact-list, to remove the last fact with index f-3, enter the retract command and then check your facts as follows.

CLIPS> (retract 3)
CLIPS> (facts)
f-0 (initial-fact)
f-1 (animal-is duck)
f-2 (animal-sound quack)
For a total of 3 facts.
CLIPS>

CLIPS issues an error message if you try to retract a non-existent fact.

You can also retract multiple facts at once, as in (retract 1 3 4) or even use the wild card * to retract all the facts, as in (retract *).

CLIPS provides several commands to help you debug programs. One command allows you to continuously watch facts being asserted and retracted. This is more convenient than having to type in a (facts) command over and over again and trying to figure out what's changed in the fact- list.

To start watching facts, enter the command (watch facts) as shown in the following example.

CLIPS> (clear)
CLIPS> (watch facts)
CLIPS> (assert (animal-is duck))
==> f-1
(animal-is duck)
<Fact-1>
CLIPS>

The right double arrow symbol, ==>, means that a fact is entering memory while the left double arrow indicates a fact is leaving memory, as shown following.

CLIPS> (reset)
<== f-0 (initial-fact)
<== f-1 (animal-is duck)
==> f-0 (initial-fact)
CLIPS> (assert (animal-is duck))
==> f-1 (animal-is duck)
<Fact-1>
CLIPS> (retract 1)
<== f-1 (animal-is duck)
CLIPS> (facts)
f-0 (initial-fact)
For a total of 1 fact.
CLIPS>

The (watch facts) command provides a record that shows the dynamic or changing state of the fact-list. In contrast, the (facts) command show the static state of the fact-list since it displays the current contents of the fact-list. To turn off watching facts, enter (unwatch facts).

There are a number of things you can watch. These include the following, which are described in more detail in the CLIPS Reference Manual. The comment in CLIPS begins with a semicolon. Everything after the semicolon is ignored by CLIPS.

(watch facts)
(watch instances)         ; used with objects
(watch slots)             ; used with objects
(watch rules)
(watch activations)
(watch messages)          ; used with objects
(watch message-handlers)  ; used with objects
(watch generic-functions)
(watch methods)           ; used with objects
(watch deffunctions)
(watch compilations)      ; on by default
(watch statistics)
(watch globals)
(watch focus)
(watch all)            ; watch everything

As you use more of the capabilities of CLIPS, you'll find these (watch) commands very helpful in debugging. To turn off a (watch) command, enter an unwatch command. For example, to turn off watching compilations, enter (unwatch compilations). And so on.

When multiple activations are on the agenda, CLIPS automatically determines which activation is appropriate to fire. CLIPS orders the activations on the agenda in terms of increasing priority or salience.

The part of the rule before the arrow is called the left-hand side (LHS) and the part of the rule after the arrow is called the right-hand side (RHS). If no patterns are specified, CLIPS automatically activates the rule when a (reset) command is entered.

CLIPS always executes the actions on the RHS of the highest priority rule on the agenda. This rule is then removed from the agenda and the actions of the new highest salience rule is executed. This process continues until there are no more activations or a command to stop is encountered.

You can check what's on the agenda with the agenda command. For example,

CLIPS> (agenda)
0 duck: f-1
For a total of 1 activation.
CLIPS>

The first number 0 is the salience of the duck activation, and f-1 is the fact-identifier of the fact, (animal-is duck), which matches the activation. If the salience of a rule is not declared explicitly, CLIPS assigns it the default value of zero, where the possible salience values range from -10,000 to 10,000. Here we'll use the definition of the term default as meaning the standard way.

If there is only one rule on the agenda, that rule will fire. Since the LHS pattern of the duck-sound rule is (animal-is duck) this pattern will be satisfied by the fact (animal-is duck) and so the duck-sound rule should fire.

Each field of the pattern is said to be a literal constraint. The term literal means having a constant value, as opposed to a variable whose value is expected to change. In this case, the literals are animal-is and duck.

To make a program run, just enter the run command. Type (run) and press the carriage return key. Then do a (facts) to check that the fact was asserted by the rule.

CLIPS> (run)
CLIPS> (facts)
f-0 (initial-fact)
f-1 (animal-is duck)
f-2 (sound-is quack)
For a total of 3 facts.
CLIPS>

Before going on, let 's save the duck rule with the save command so that you don 't have to type it in again (if you haven 't already saved it in an editor). Just enter a command such as

(save "duck.clp")

to save the rule from CLIPS memory to disk and name the file duck.clp where the .clp is simply a convenient extension to remind us this is a CLIPS source code file. Note that saving the code from CLIPS memory like this will only preserve the optional rule-header comment in quotes and not any semicolon comments.

An interesting question may occur to you at this time. What if you (run) again? There is a rule and a fact which satisfies the rule, so the rule should fire. However, if you try this and (run) again, you 'll see that the rule won 't fire. This may be somewhat frustrating. However, before you do something drastic to ease your frustration — like kicking your pet duck — you need to know a little more about some basic principles of expert systems.

A rule is activated if its patterns are matched by...

• 1. a brand new pattern entity that did not exist before or,
• 2. a pattern entity that did exist before but was retracted and reasserted, i.e., a clone of the old pattern entity, and thus now a new pattern entity.

The rule, and indices of the matching patterns, is the activation. If either the rule or the pattern entity, or both change, the activation is removed. An activation may also be removed by a command or an action of another rule that fired before and removed the conditions necessary for activation.

The Inference Engine sorts the activations according to their salience. This sorting process is called conflict resolution because it eliminates the conflict of deciding which rule should fire next. CLIPS executes the RHS of the rule with the highest salience on the agenda, and removes the activation. This execution is called firing the rule in analogy with the firing of a neuron. A neuron emits a voltage pulse when an appropriate stimulus is applied. After a neuron fires, it undergoes refraction and cannot fire again for a certain period of time. Without refraction, neurons would just keep firing over and over again on exactly the same stimulus.

Without refraction, expert systems always would be caught in trivial loops. That is, as soon as a rule fired, it would keep firing on that same fact over and over again. In the real world, the stimulus that caused the firing eventually would disappear. For example, a real duck might swim away or get a job in the movies. However, in the computer world, once data is stored, it stays there until explicitly removed or the power is turned off.

The following example shows activations and firing of a rule. Notice that the (watch) commands are used to more carefully show every fact and activation. The arrow going to the right means an entering fact or activation while an arrow to the left would mean an exiting fact or activation.

CLIPS> (clear)
CLIPS>
(defrule duck
  (animal-is duck)
=>
  (assert (sound-is quack)))
CLIPS> (watch facts)
CLIPS> (watch activations)
CLIPS> (assert (animal-is duck))
==> f-1 (animal-is duck)
; Activation salience is 0 by default,
; then rule name:pattern entity index
==> Activation 0 duck: f-1
<Fact-1>
; Notice that duplicate fact
; cannot be entered
CLIPS> (assert (animal-is duck))
FALSE
CLIPS> (agenda)
0 duck: f-1
For a total of 1 activation.
CLIPS> (run)
==> f-2 (sound-is quack)
; Nothing on agenda after rule fires
; Even though fact matches rule,
; refraction will not allow this
; activation because the rule already
; fired on this fact
CLIPS> (agenda)
CLIPS> (facts)
f-0 (initial-fact)
f-1 (animal-is duck)
f-2 (sound-is quack)
For a total of 3 facts.
CLIPS> (run)
CLIPS>

You can make the rule fire again if you retract the fact and then assert it as a new fact.

Sometimes you may want to see a rule while you 're in CLIPS. There 's a command called ppdefrule – the pretty print rule – that prints a rule. To see a rule, specify the rule name as an argument to ppdefrule. For example,

CLIPS> (ppdefrule duck)
(defrule MAIN::duck
  (animal-is duck)
  =>
  (assert (sound-is quack)))
CLIPS>

CLIPS puts different parts of the rule on different lines for the sake of readability. The patterns before the arrow are still considered the LHS and the actions after the arrow are still considered the RHS of the rule. The term MAIN refers to the MAIN module that this rule is in by default. You can define modules to put rules in analogous to the statements that may be put in different packages, modules, procedures, or functions of other programming languages. The use of modules make it easier to write expert systems having many rules since these may be grouped together with their own agendas for each module. For more information, see the CLIPS Reference Manual.

What if you want to print a rule but can't remember the name of the rule? No problem. Just use the rules command in response to a CLIPS prompt and CLIPS will print out the names of all the rules. For example, enter

CLIPS> (rules)
duck
For a total of 1 defrule.
CLIPS>

Besides asserting facts in the RHS of rules, you also can print out information using the printout function. CLIPS also has a carriage return/linefeed keyword called crlf which is very useful in improving the appearance of output by formatting it on different lines. For a change, the crlf is not included in parentheses. As an example,

CLIPS>
(defrule duck
  (animal-is duck)
=>
  ;; Be sure to type in the "t"
  (printout t "quack" crlf))
==> Activation 0 duck: f-1
CLIPS> (run)
quack
CLIPS>

The output is the text within the double quotes. Be sure to type the letter t following the printout command. This tells CLIPS to send the output to the standard output device of your computer. Generally, the standard output device is your terminal (hence the letter t after printout). However, this may be redefined so that the standard output device is some other device, such as a modem or disk.

The load command loads in the rule that you had previously saved to disk in the file duck.clp or whatever name and directory that you had saved it under. You can load a file of rules made on a text editor into CLIPS using the load command.

A faster way to load files is to first save them in a machine readable binary format with the save binary command called bsave. The load binary command, bload, can then be used to read these binary rules into CLIPS memory much faster since the files do not have to be re-interpreted by CLIPS.

Two other useful commands allow you to save and load facts using a file. These are save-facts and load-facts. The (save-facts) will save all the facts in the fact-list to a file while (load-facts) will load in the facts from a file into the fact-list.

The batch command allows you to execute commands from a file as if they were typed in at the top-level.

The declare salience command provides explicit control over which rules will be put on the agenda. You must be careful in using this feature too freely lest your program become too controlled. The set-incremental-reset command prohibits rules from seeing facts that are entered before the rules are entered. The command to get the current value of incremental reset is get-incremental-reset. One way to make a rule fire again is to force the rule to be re-activated by the refresh rule command.

Another useful command provides an interface to your operating system. The system command allows the execution of operating system commands or executables within CLIPS. For more information on all these topics, see the CLIPS Reference Manual.

In expert systems, one use of the term strategy is in conflict resolution of activations. Now you might say, Well, I 'll just design my expert system so that only one rule can possibly be activated at one time. Then there is no need for conflict resolution. The good news is that if you succeed, conflict resolution is indeed unnecessary. The bad news is that this success proves that your application can be well represented by a sequential program. So you should have coded it in C, Java, or Ada in the first place and not bothered writing it as an expert system.

CLIPS offers seven different modes of conflict resolution: depth, breadth, LEX, MEA, complexity, simplicity, and random. It 's difficult to say that one is clearly better than another without considering the specific application. Even then, it may be difficult to judge which is best. For more information on the details of these strategies, see the CLIPS Reference Manual.

The depth strategy is the standard default strategy of CLIPS. The default setting is automatically set when CLIPS is first started. Afterwards, you can change the default setting. In the depth strategy, new activations are placed on the agenda after activations with higher salience, but before activations with equal or lower salience. All this simply means is that the agenda is ordered from highest to lowest salience.

Now that all these different optional settings are available, be sure that before you run an expert system developed by someone else, that your settings are the same as theirs. Otherwise, you may find the operation is inefficient or even incorrect. In fact, it's a good idea to explicitly encode all the settings in any system that you develop so that it will be configured properly.

As you work with CLIPS, you may become tired of typing in the same assertions from the top- level. If you are going to use the same assertions every time a program is run, you can first load assertions from a disk using a batch file. An alternative way to enter facts is by using the define facts keyword, deffacts. For example,

CLIPS> (unwatch facts)
CLIPS> (unwatch activations)
CLIPS> (clear)
CLIPS>
(deffacts walk "Some facts about walking"
  (status walking) ; fact to be asserted
  (walk-sign walk)) ; fact to be asserted
CLIPS> (reset)
; reset causes facts from
; deffacts to be asserted
CLIPS> (facts)
f-0 (initial-fact)
f-1 (status walking)
f-2 (walk-sign walk)
For a total of 3 facts.
CLIPS>

The required name of this deffacts statement, walk, follows the deffacts keyword. Following the name is an optional comment in double quotes. Like the optional comment of a rule, the (deffacts) comment will be retained with the (deffacts) after it 's been loaded by CLIPS. After the name or comment are the facts that will be asserted in the fact-list. The facts in a deffacts statement are asserted using the CLIPS (reset) command.

The (initial-fact) is put in automatically by a (reset). The fact-identifier of the initial-fact is always f-0. Even without any deffacts statements, a (reset) always will assert an (initial-fact). In prior versions of CLIPS this fact was used to activate some types of rules, but is no longer used for this purpose. It is provided for backwards compatibility for programs which explicitly match against this fact.

The (reset) has an advantage compared to a (clear) command in that (reset) doesn 't get rid of all the rules. The (reset) leaves your rules intact. Like (clear), it removes all activated rules from the agenda and also removes all old facts from the fact-list. Giving a (reset) command is a recommended way to start off program execution, especially if the program has been run before and the fact-list is cluttered with old facts.

In summary, the (reset) does three things for facts:

• 1. It removes existing facts from the fact-list, which may remove activated rules from the agenda.
• 2. It asserts (initial-fact).
• 3. It asserts facts from existing (deffacts) statements.

Actually, the (reset) also does corresponding operations on objects. It deletes instances, creates initial-object, and asserts instances from definstances.

The undeffacts command excises a (deffacts) from asserting facts by eliminating the deffacts from memory. For example,

CLIPS> (undeffacts walk)
CLIPS> (reset)
CLIPS> (facts)
f-0 (initial-fact)
For a total of 1 fact.
CLIPS>

This example demonstrates how the (deffacts) has removed walk. To restore a deffacts statement after an (undeffacts) command, you must enter the deffacts statement again. You can even get rid of initial-fact with (undeffacts). In addition to facts, CLIPS also allows you to eliminate rules selectively by using the undefrule.

You can watch rules firing and watch activations on the agenda. The watch statistics prints information about the number of rules fired, run time, rules per second, mean number of facts, maximum number of facts, mean number of activations, and maximum number of activations. The statistics information may be useful in tuning up an expert system to optimize its speed. Another command, called watch compilations, shows information when rules are being loaded. The watch all command will watch everything.

Printing of watch information to the screen or to disk with the dribble command will slow down your program somewhat because CLIPS uses more time to print or to save to disk. The dribble-on command will store everything entered in the Dialog Window to a disk file until the dribble-off command is entered. This is convenient in providing a permanent record of everything that happens. These commands are as follows.

(dribble-on <filename>)
(dribble-off <filename>)

Another useful debugging command is (run) which takes an optional argument of the number of rule firings. For example, a (run 21) command would tell CLIPS to run the program and then stop after 21 rule firings. A (run 1) command allows you to step through a program firing one rule at a time.

Just like many other programming languages, CLIPS also gives you the capability of setting breakpoints. A breakpoint is simply an indicator to CLIPS to stop execution just prior to executing a specified rule. A breakpoint is set by the set-break command. The remove-break command will remove a breakpoint that has been set. The show-breaks will list all the rules which have breakpoints set. The syntax of these commands for the argument <rulename> is shown below:

(set-break <rulename>)
(remove-break <rulename>)
(show-breaks)

You may encounter a situation in which you are certain a rule should be activated but isn 't. While it is possible that this is due to a bug in CLIPS, it 's not very likely because of the great skill of the people who programmed CLIPS.

In most cases, the problem occurs because of the way that you wrote the rule. As an aid to debugging, CLIPS has a command called matches that can tell you which patterns in a rule match facts. Patterns which do not match prevent the rule from becoming activated. One common reason that a pattern won't match a fact results from misspelling an element in the pattern or in the assertion of the fact.

The argument of (matches) is the name of the rule to be checked for matches. To see how (matches) works, first (clear), then enter the following rule.

(defrule take-a-vacation
  (work done) ; Conditional element 1
  (money plenty) ; Conditional element 2
  (reservations made) ; Conditional element 3
=>
  (printout t "Let's go!!!" crlf))

The following shows how (matches) is used. Enter the commands as shown. Notice that (watch facts) is turned on. This is a good idea when you are asserting facts manually since it gives you an opportunity to check the spelling of facts.

CLIPS> (watch facts)
CLIPS> (assert (work done))
==> f-1 (work done)
<Fact-1>
CLIPS> (matches take-a-vacation)
Matches for Pattern 1
f-1
Matches for Pattern 2
  None
Matches for Pattern 3
  None
; CE is conditional element
Partial matches for CEs 1 - 2
  None
Partial matches for CEs 1 - 3
  None
Activations
  None
CLIPS>

The fact with fact-identifier f-1 matches the first pattern or conditional element in the rule and is reported by (matches). Given that a rule has N patterns, the term partial matches refers to any set of matches of the first N-1 patterns with facts. That is, the partial matches begin with the first pattern in a rule and end with any pattern up to but not including the last (Nth) pattern. As soon as one partial match cannot be made, CLIPS does not check any further. For example, a rule with four patterns would have partial matches of the first and second patterns and also of the first, second, and third patterns. If all N patterns match, the rule will be activated.

Some additional commands are useful with deffacts. For example, the command list-deffacts will list the names of currently loaded deffacts in CLIPS. Another useful command is ppdeffacts which prints the facts stored in a deffacts.

Other functions allow you to manipulate strings easily:

assert-string

Performs a string assertion by taking a string as argument and asserted as a non-string fact.

str-cat

Constructs a single-quoted string from individual items by string concatenation.

str-index

Returns a string index of the first occurrence of a substring.

sub-string

Returns a substring from a string.

str-compare

Performs a string compare.

str-length

Returns the string length which is the length of a string.

sym-cat

Returns a concatenated symbol.

If you want to printout a multifield variable without parentheses, the simplest way is by using the string implode function, implode$.

CLIPS can read the information that you type from the keyboard using the read function. The following example shows how (read) is used to input data. Note that no extra (crlf) is needed after the (read) to put the cursor on a new line. The (read) automatically resets the cursor to a new line.

CLIPS> (clear)
CLIPS>
(defrule read-input
=>
  (printout t "Name a primary color" crlf)
  (assert (color (read))))
CLIPS>
(defrule check-input
  ?color <-
    (color ?color-read&red|yellow|blue)
=>
  (retract ?color)
  (printout t "Correct" crlf))
CLIPS> (reset)
CLIPS> (agenda)
0  read-input: *
For a total of 1 activation.
CLIPS> (run)
Name a primary color
red
Correct
CLIPS> (reset)
CLIPS> (run)
Name a primary color
green
CLIPS>
; No "correct"

The rule is designed to use keyboard input on the RHS, so it 's convenient to trigger the rule by not specifying any patterns on the LHS so it will automatically be activated when a (reset) occurs. When the activation for the read-input rule is displayed by the (agenda) command, an * is printed rather than a fact identifier such as f-1. The * is used to indicate that the pattern is satisfied, but not by a specific fact.

The (read) function is not a general-purpose function that will read anything you type on the keyboard. One limitation is that (read) will read only one field. So if you try to read

primary color is red

only the first field, primary, will be read. To (read) all the input, you must enclose the input within double quotes. Of course, once the input is within double quotes, it is a single literal field. You can then access the substrings primary, color, is, and red with the str-explode or sub-string functions.

The second limitation of (read) is that you can 't input parentheses unless they are within double quotes. Just as you can 't assert a fact containing parentheses, you can 't (read) parentheses directly except as literals.

The readline function is used to read multiple values until terminated by a carriage return. This function reads in data as a string. In order to assert the (readline) data, an (assert-string) function is used to assert the nonstring fact, just as input by (readline). A top-level example of (assert-string) follows.

CLIPS> (clear)
CLIPS> (assert-string "(primary color is red)")
<Fact-1>
CLIPS> (facts)
f-0 (initial-fact)
f-1 (primary color is red)
For a total of 2 facts.
CLIPS>

Notice that the argument of (assert-string) must be a string The following shows how to assert a fact of multiple fields from (readline).

CLIPS> (clear)
CLIPS>
  (defrule test-readline
=>
  (printout t "Enter input" crlf)
  (bind ?string (readline))
  (assert-string (str-cat "(" ?string ")")))
CLIPS> (reset)
CLIPS> (run)
Enter input
primary color is red
CLIPS> (facts)
f-0 (initial-fact)
f-1 (primary color is red)
For a total of 2 facts.
CLIPS>

Since (assert-string) requires parentheses around the string to be asserted, the (str-cat) function is used to put them around ?string.

Both (read) and (readline) also can be used to read information from a file by specifying the logical name of the file as the argument. For more information, see the CLIPS Reference Manual.

CLIPS is a rule-based language that uses a very efficient pattern-matching algorithm called the Rete Algorithm, devised by Charles Forgy of Carnegie-Mellon University for his OPS shell. The term Rete is Latin for net, and describes the software architecture of the pattern-matching process.

It is very difficult to give precise rules that will always improve the efficiency of a program running under the Rete Algorithm. However, the following should be taken as general guidelines that may help:

• Put the most specific patterns in a rule first. Patterns with unbound variables and wildcards should be lower down in the list of rule patterns. A control fact should be put first in the patterns.
• Patterns with fewer matching facts should go first to minimize partial matches.
• Patterns that are often retracted and asserted, volatile patterns, should be put last in the list of patterns.

As you can see, these guidelines are potentially contradictory. A non-specific pattern may have few matches (see guidelines 1 and 2). Where should it go? The overall guideline is to minimize changes of the partial matches from one cycle of the Inference Engine to the next. This may require much effort by the programmer in watching partial matches. An alternative solution is simply to buy a faster computer, or an accelerator board. This is becoming more attractive since the price of hardware always goes down while the price of human labor always goes up. Because CLIPS is designed for portability, any code developed on one machine should work on another.

The test conditional element provides a very powerful way by which to compare numbers, variables, and strings on the LHS. The (test) is used as a pattern on the LHS. A rule will only be triggered if the (test) is satisfied together with other patterns.

Many predefined functions are provided by CLIPS. Logical functions are:

• not: Boolean not
• and: Boolean and
• or: Boolean or

Arithmetic functions are:

• /: Division
• *: Multiplication
• +: Addition
• -: Subtraction

Comparison functions are:

• eq: Equal (any type). Compares type and magnitude.
• neq: Not equal (any type).
• =: Equal (numeric type). Compares magnitude.
• <>: Not equal (numeric type).
• >=: Greater than or equal to
• >: Greater than.
• <=: Less than or equal to.
• <: Less than.

All the comparison functions except eq and neq will give an error message if they are used to compare a number and non-number. If the type is not known in advance, the eq and neq functions should be used. The eq function checks for the same magnitude and type of its arguments while the = function only checks the magnitude of its (numeric) arguments and doesn 't care if they 're integer or floating-point.

The logical functions of CLIPS are and, or, and not. They can be used in expressions as Boolean functions. In CLIPS, true and false are represented by the symbols TRUE and FALSE. Note that upper-case must be used for logical values in CLIPS.

In addition to all the predefined functions, you may write external functions or user-defined functions in C, Ada, or other procedural languages and link to CLIPS. These external functions are then used as you would any predefined function.

CLIPS also gives you the capability of specifying an explicit and conditional element, an or conditional element, and a not conditional element on the LHS. The absence of a fact is specified as a pattern on the LHS using the not conditional element.

The alteration of our information to conform to reality is called truth maintenance. That is, we try to maintain the state of our minds to contain only true information so as to minimize conflicts with the real world.

While people can do this fairly easily (practice makes perfect), it 's difficult for computers because they don 't normally know which pattern entities are logically dependent on other pattern entities. CLIPS has a feature to support truth maintenance which will internally tag those pattern entities which are logically dependent on others. If these other pattern entities are retracted, CLIPS will automatically retract the logically dependent ones. The logical conditional element uses the keyword logical around a pattern to indicate that the matching pattern entities provide logical support to the assertions on the RHS.

Although the logical support works for assertions, it does not reassert retracted facts. The moral is, if you lose something due to erroneous information, you can 't get it back (like losing money on your stockbrokers advice.)

CLIPS has two functions to help with logical support. The dependencies function lists the partial matches from which a pattern entity receives logical support, or none if there is no support. The second logic function is dependents which lists all pattern entities which receive logical support from a pattern entity.

The connective constraint, uses &, |, or ~. Another type of field constraint is called a predicate constraint and is often used for pattern matching of more complex fields. The purpose of a predicate constraint is to constrain a field depending on the result of a Boolean expression. If the Boolean returns FALSE, the constraint is not satisfied and the pattern matching fails. You 'll find that the predicate constraint is very useful with numeric patterns.

A predicate function is one which returns a FALSE or a non-FALSE value. The colon, : followed by a predicate function is called a predicate constraint. The : may be preceded by &, |, or ~ or may stand by itself as in the pattern (fact :(> 2 1)). It is typically used with the & connective constraint as &:. The following list contains some of the predicate functions defined by CLIPS:

• (evenp <arg>): check if <arg> is even number.
• (oddp <arg>): check if <arg> is odd number.
• (floatp <arg>): check if <arg> is floating-point number.
• (integerp <arg>): check if <arg> is integer.
• (numberp <arg>): check if <arg> is float or integer.
• (stringp <arg>): check if <arg> is string.
• (symbolp <arg>): check if <arg> is symbol.
• (lexemep <arg>): check if <arg> is symbol or string.
• (multifieldp <arg>): check if <arg> is multifield value.
• (pointerp <arg>): check if <arg> is external address.

There are often cases in which it's convenient to have values which are globally known in an expert system. For example, it is inefficient to have to redefine universal constants such as π.

CLIPS provides the defglobal construct so that values may be universally known to all rules.

Another type of useful function is random numbers. CLIPS has a random function which returns a random integer value. The random number function of CLIPS actually returns pseudorandom numbers, which means they are not truly random but are generated by a mathematical formula. For most purposes the pseudorandom numbers will be fine. Note that the random function of CLIPS uses the ANSI C library function rand which may not be available on all computers that do not adhere to this standard. For more information on all these topics, please see the CLIPS Reference Manual.

In addition to control facts to control the execution of programs, CLIPS provides a more direct way of control by the explicit assignment of salience to rules. The main problem associated with explicitly using salience while you were just starting to learn CLIPS is the tendency to overuse salience and write sequential programs. This overuse defeats the whole purpose of using a rule-based language, which is to provide a natural vehicle for those applications best represented by rules. In the same way, procedural languages are best for strong control-oriented applications, while object-oriented languages are best for representing objects. CLIPS has keywords called declare salience which can be used to explicitly set the priority of rules.

Salience is set using a numeric value ranging from the smallest value of -10000 to the highest of 10000. If a rule has no salience explicitly assigned by the programmer, CLIPS assumes a salience of zero. Notice that a salience of zero is midway between the largest and smallest salience values. A salience of zero does not mean that the rule has no salience but, rather, that it has an intermediate priority level.

CLIPS provides some procedural programming structures that can be used on the RHS. These structures are the while and if [...] then [...] else [...] that also are found in modern high-level languages such as Ada, C, and Java.

Another useful function with (while) loops is break which ends the currently executing (while) loop. The return function immediately ends the currently executing deffunction, generic function, method, or message-handler.

Any function may be called from the RHS, which greatly contributes to the power of CLIPS. Many other CLIPS functions are available that may return with numbers, symbols, or strings. These functions may be used for their return values or for their side-effects. An example of a function only used for its side-effect is (printout). The value returned by (printout) is meaningless. The importance of (printout) is in its side-effect of output. In general, functions may have nested arguments if appropriate to your desired effect.

Before a file can be accessed for reading or writing, it must be opened using the open function. The number of files that can be opened at once is dependent on your operating system and hardware. When you no longer need to access a file, you should close it with the close function. Unless a file is closed, there is no guarantee that the information written to it will be saved.

The logical name of a file is how CLIPS identifies the file. The logical name is a global name by which CLIPS knows this file in all rules. Although the logical name could be identical to the filename, you may want to use something different. Another advantage of a logical name is that you can easily substitute a different filename without making major program changes.

The function to read data from a file is the familiar (read) or (readline). The only new thing that you have to do is to specify the logical name from which to read as the argument of (read) or (readline).

To (read) more than one field, you must use a loop. Even with (readline), a loop is necessary to read multiple lines. A loop can be written by having one rule trigger another or with a while-loop. The loop should not try to read past the end of file or the operating system will issue an error message. To help prevent this, CLIPS returns an EOF symbolic field if you try to read past the end of file (EOF).

The evaluation function, eval, is used for evaluating any string or symbol except the def type constructs such as defrule, deffacts, etc., as if entered at the top-level. The build function takes care of the def type constructs. The (build) function is the complement of (eval). The build function evaluates a string or symbol as if it were entered at the top-level and returns TRUE if the argument is a legal def-type construct such as (defrule), (deffacts), and so forth.

A key characteristic of good program design is flexibility. Unfortunately, the rigid methodology of structured programming techniques does not provide the needed flexibility for fast, reliable, and efficient changes. The object-oriented programming (OOP) paradigm. provides this flexibility.

The term paradigm comes from the Greek word paradeigma which means a model, example, or pattern. In computer science, a paradigm is a consistent, organized methodology for trying to solve a problem. Today, there are many programming paradigms such as OOP, procedural, rule- based, and connectionist. The term artificial neural systems, is a modern synonym for the older term connectionist.

Traditional programming is procedural because it emphasizes algorithms or procedures in solving problems. Many languages have been developed to support this procedural paradigm, such as Pascal, C, Ada, FORTRAN, and BASIC. These languages have also been adapted for object-oriented design (OOD) by either adding extensions or imposing a design methodology on the programmers. In contrast, new languages have been developed to provide OOP, which is not the same as OOD. You can do OOD in any language, even assembly language.

CLIPS provides three paradigms: rules, objects, and procedures. You will learn more about the objects in the CLIPS Object-Oriented Language (COOL) which is integrated with the rule and procedural based paradigms of CLIPS. CLIPS supports the procedural paradigm through generic functions, deffunctions, and user-defined external functions. Depending on the application, you can use rules, objects, procedures, or a combination.

Rather than imposing a single paradigm on the user, our philosophy is that a variety of specialized tools, a multi-paradigm approach, is better than trying to force everyone to use a single general purpose tool. As an analogy, while you could use a hammer and nails for fastening everything, there are cases in which other fasteners are preferred. For example, imagine fastening your pants with a hammer and nails instead of a zipper.

In OOP a class is a template which describes the common characteristics or attributes of objects. Note that this use of the term template is not the same as a deftemplate as described in an earlier chapter. Here, the word template is used in the sense of a tool that is used to build objects having common attributes. As analogies, a straightedge is a template for drawing straight lines while a cookie-cutter is a curvaceous template.

Classes of objects are arranged in a hierarchy or in a graph to describe the relationships of objects in a system. Each class is an abstraction of a real-world system or some other logical system that we are trying to model. For example, one abstract model of a real-world system might be an automobile. Another abstract model of a logical system could be financial instruments such as stocks and bonds, or complex numbers. The term abstraction refers to (1) the abstract description of a real-world object or other system that we are trying to model, or (2) the process of representing a system in terms of classes. Abstraction is one of the five generally accepted features of a true OOP language. The others are inheritance, encapsulation, polymorphism and dynamic binding. These terms will be explained in detail as you read through this section. CLIPS supports all five of these features.

The term abstract means that we are not concerned with nonessential details. An abstract description of a complex system is a simplified description that concentrates on relevant information for a specific purpose. Thus, the system is represented by a simpler, easier to understand model. As a familiar example, when certain people drive cars, they utilize an abstract model of driving that consists of two items — the steering wheel and the accelerator. That is, these people are not concerned with the hundreds of components that make up an automobile, nor the theory of internal combustion engines, traffic laws, and so forth. Knowing only how to use the steering wheel and accelerator is their abstract model of driving.

One of the five fundamental features of OOP is inheritance. Classes are arranged in a hierarchy with the most general classes at the top and the more specialized classes below. This allows new classes to be easily defined as specialized refinements or modifications of existing classes.

The use of inheritance can greatly speed up software development and increase reliability because new software does not need to be created from scratch each time a new program is made. OOP makes it easy to utilize reusable code. OOP programmers often make use of object libraries consisting of hundreds or thousands of objects. These objects can be used or modified as desired in a new program. In addition to public domain object libraries, a number of companies market commercial object libraries. Although the concept of reusable software components has been around since the early days of FORTRAN subroutine libraries in the 1960s, the concept has never before been so successfully used for general software development.

In order to define a class, you must specify one or more parent classes or superclasses of the class to be defined. As an analogy to superclasses, every person has parents; people do not spontaneously come into existence (although sometimes you may wonder if certain people really had parents.) The opposite of a superclass is a child class or subclass.

This determines the inheritance of the new class. A subclass inherits attributes from one or more superclasses. The term attribute in COOL refers to the properties of an object, which are named slots that describe it. For example, an object to represent a person might have slots for name, age, address, and so forth.

An instance is an object that has values for the slots such as John Smith, 28, 1000 Main St., Clear Lake City, TX. Lower-level classes automatically inherit their slots from higher-level classes, unless the slots are explicitly blocked. New slots are defined in addition to the inherited slots to set all the attributes that describe the class.

An object's behavior is defined by its message-handlers, or handlers for short. A message-handler for an object responds to messages and performs the required actions. For example, sending the message

(send [John_Smith] print)

would cause the appropriate message-handler to print the values of the slots of the instance John_Smith. Instances are generally specified within brackets, [ ]. A message begins with the send function, followed by the instance name, message name, and any required arguments. For example, in the case of the print message, there are no arguments. An object in CLIPS is an instance of a class.

The encapsulation of slots and handlers inside an object is another of the five generally accepted features of an OOP. The term encapsulated means that a class is defined in terms of its slots and handlers. Although an object of a class may inherit slots and handlers from its superclasses, with a few exceptions discussed later, the object's slot values cannot be altered or examined without sending a message to the object.

The root class or simply root of CLIPS is a predefined system class called OBJECT. The predefined system class USER is a subclass of OBJECT.

As an example, suppose we wanted to define a class called UPPIE, which is a colloquial term for urban professional. Note that in this section, we'll follow the convention of writing classes in all uppercase.

UPPIE is defined as a subclass of USER.

CLIPS supports only is-a relationships.

The is-a link indicates the inheritance of slots from a class to its subclass. A class may have zero or more subclasses. All classes except OBJECT must have a superclass. Since UPPIE also inherits all slots of USER, and USER inherits all slots of OBJECT, it follows that UPPIE inherits all slots of OBJECT too. The same principle of inheritance also applies to the message-handlers of each class. For example, UPPIE inherits all the handlers of USER and OBJECT.

The inheritance of slots and handlers is particularly important in OOP since it means that you do not have to redefine the properties and behavior of each new class of objects that is defined. Instead, each new class inherits all the properties and behavior from its higher-level classes. Since the new behavior is inherited, it may substantially reduce the verification and validation (V&V) of the handlers. V&V essentially means that the product was built properly and that it meets the requirements. The task of verifying and validating software may take more time and money than the software development itself, especially if the software affects human life and property. Inheritance of handlers allows for efficient reuse of existing code and speeds up development.

Classes are defined in CLIPS using the defclass construct. The UPPIE class is defined in one statement as follows.

(defclass UPPIE (is-a USER))

You do not have to enter the USER or the OBJECT classes since these are predefined classes and so CLIPS already knows their relationship. In fact, if you try to define USER or OBJECT, an error message will result since you cannot change the predefined classes, unless you change the source code of CLIPS.

Since CLIPS is case-sensitive, commands and functions must be entered in lowercase. Predefined system classes such as USER and OBJECT must be entered in uppercase. Although you can enter user-defined classes in lowercase or uppercase, we will follow the convention of using all uppercase for classes for the sake of readability.

The basic format of the defclass command to define classes only, and not slots, is,

(defclass <class>
(is-a <direct-superclasses>))

The list of classes, <direct-superclasses>, is called a direct superclass precedence list because it defines how a class is linked to its direct superclasses. The direct superclasses of a class are the one or more classes named after the is-a keyword. In our example, class DUCKLING is the direct superclass of DUCK. Note that at least one direct superclass must be given in the direct superclass precedence list.

If the direct superclass list was as follows,

(defclass DUCK
(is-a DUCKLING USER OBJECT))

then USER and OBJECT would also be direct superclasses of DUCK. In this example, it makes no difference whether USER and OBJECT are specified in addition to DUCKLING. In fact, since USER and OBJECT are predefined classes that are always linked such that USER is-a OBJECT, and OBJECT is the root, you need never specify them except when defining a subclass of USER. Since USER only inherits from OBJECT, it is not necessary to specify OBJECT if USER is specified.

The indirect superclasses of a class are all the classes not named after the is-a that contribute slots and message-handlers by inheritance. In our example, the indirect superclasses are USER and OBJECT. A class inherits slots and message-handlers from all its direct and indirect superclasses. Thus, DUCK inherits from DUCKLING, USER, and OBJECT.

The root class OBJECT is the only class that does not have a superclass.

Using this fancy new terminology allows us to state the Principle of OOP Inheritance: A class may inherit from all its superclasses.

This is a simple, yet powerful concept fully exploited in OOP. This principle means that slots and message-handlers may be inherited to save us the trouble of redefining them for new subclasses. In addition, slots may be easily customized for new subclasses as modifications and as composites of superclass slots. By allowing easy and flexible reuse of existing code, program development time and cost are decreased. In addition, the reuse of working, existing code minimizes the amount of verification and validation needed. All these advantages facilitate the program maintenance tasks of debugging, modification, and enhancement once the code is released.

The reason for using may in the principle is to emphasize that inheritance of slots from a class may be blocked by including a no-inherit facet in the class slot definition.

The direct and indirect classes of a class are all those that lie on an inheritance path to OBJECT. An inheritance path is a set of connected nodes between the class and OBJECT. In our example, the single inheritance path of DUCK is DUCK, DUCKLING, USER, and OBJECT. In some cases a class has multiple inheritance paths to OBJECT.

CLIPS provides a number of functions to show information about classes, such as predicate functions to test whether a class is a superclass or subclass of another.

The superclassp function returns TRUE if <class1> is a superclass of <class2>, and FALSE otherwise. The subclassp function returns TRUE if <class1> is a subclass of <class2>, and FALSE otherwise. The general form of both functions is

(function <class1> <class2>)

Now, to check to see if CLIPS accepted all these new classes. One way of doing this is with the list-defclasses command. Following is the output of the command.

CLIPS> (list-defclasses)
FLOAT
INTEGER
SYMBOL
STRING
MULTIFIELD
EXTERNAL-ADDRESS
FACT-ADDRESS
INSTANCE-ADDRESS
INSTANCE-NAME
OBJECT
PRIMITIVE
NUMBER
LEXEME
ADDRESS
INSTANCE
USER
INITIAL-OBJECT
UPPIE
CHILD
SUPPIE
MUPPIE
YUPPIE
PUPPIE
YUKKIE
For a total of 24 defclasses.
CLIPS>

Notice that the (list-defclasses) command does not indicate the hierarchical class structure. That is, list-defclasses does not indicate which classes are subclasses or superclasses of others.

The browse-classes command shows the class hierarchy through indentation.

CLIPS> (browse-classes)
OBJECT
PRIMITIVE
NUMBER
91INTEGER
FLOAT
LEXEME
SYMBOL
STRING
MULTIFIELD
ADDRESS
EXTERNAL-ADDRESS
FACT-ADDRESS
INSTANCE-ADDRESS *
INSTANCE
INSTANCE-ADDRESS *
INSTANCE-NAME
USER
INITIAL-OBJECT
UPPIE
SUPPIE
MUPPIE
YUPPIE
PUPPIE
YUKKIE *
CHILD
YUKKIE *
CLIPS>

The (browse-classes) command has an optional argument which specifies the starting class for the subclasses you want to see. This is convenient if you are not interested in listing all the classes.

An abstract class is designed for inheritance only. The abstract class USER cannot have direct instances defined for it, which are instances defined directly for a class. In addition to the class information, the inheritance precedence of the classes is described. This is an ordered list in which the order from left to right indicates the highest to lowest precedence that classes contribute by inheritance. The inheritance precedence lists all the superclasses of a class back to the root class OBJECT. You can also see that the direct superclasses information indicates the superclass that is one link above a class while the inheritance precedence list shows all superclasses.

Even if a class has no direct instances, it will have indirect instances if it has subclasses which have instances. The indirect instances of a class are all the instances of its subclasses.

A concrete class is allowed to have direct instances. For example, given a concrete class COW, the direct instance Elsie would be the famous TV salescow. Normally classes inheriting from abstract classes are also abstract classes. However, classes inheriting from system classes, such as USER, are considered to be concrete unless otherwise specified. So UPPIE and YUPPIE are also concrete classes.

Some other functions useful with classes are shown following.

• ppdefclass: Pretty-print the declass internal structure.
• undefclass: Eliminate class.
• describe-class: Additional information about classes.
• class-abstractp: Predicate function returns TRUE if the class is abstract.

In order to see how messages work, let's start by entering the following commands to create a user-defined DUCK class and check that it's entered. Notice that no role descriptor is specified for the DUCK class. If a class has role concrete, direct instances of the class can be created. If the role is unspecified, CLIPS determines the role by inheritance. For determining role by inheritance, system classes behave as concrete classes. Thus by default, any class inheriting from USER is a concrete class and does not need to be declared as such in order to allow direct instances to be created.

If a class has role abstract no direct instances of it can be made. Abstract classes are defined for inheritance purposes only. For example, an abstract class called PERSON could be defined whose properties such as name, address, age, height, weight, and so on are inherited by concrete classes MAN and WOMAN. A direct instance of MAN could be a man-person called Harold, and a direct instance of WOMAN is a woman-person called Henrietta.

Since classes are not objects in CLIPS, we can't send a message to make an object. Instead, the make-instance function is used to make an instance object. The basic syntax is as follows.

(make-instance [<instance-name>] of <class>
  <slot-override>)

Normally, you specify an instance-name. However, If you do not, CLIPS will generate one using the gensym* function. Slot values also can be specified.

Now that we have a duck factory, let's make some instances as follows, where the name of the instance is in brackets. Note the use of the of keyword to separate the instance name from the class name. You must include the of or a syntax error will result. Also, note that the brackets in the code mean an instance name, while brackets in the metasyntax such as for (make-instance) above, mean optional.

CLIPS> (make-instance [Dorky] of DUCK)
[Dorky]
CLIPS> (make-instance [Elsie] of COW)
[PRNTUTIL1] Unable to find class COW.
CLIPS> (make-instance Dorky_Duck of DUCK)
[Dorky_Duck]
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky] of DUCK
[Dorky_Duck] of DUCK
For a total of 3 instances.
CLIPS>

After the instance is successfully created, CLIPS responds with the name of the instance. If it is not possible to create an instance, CLIPS responds with a FALSE. Also, like the (rules) and (facts) commands, CLIPS has an instances function to print out the instances of a class. The initial- object object listed is similar to the initial-fact fact. It was provided in previous versions of CLIPS to initially activate some types of rules, but it now only provided for backwards compatibility for programs which directly reference it.

For the case of (make-instance), the brackets around the instance name is optional for a USER-defined class.

There are two important rules about instances to keep in mind.

• Only one instance of the same name may be used in a module.
• A class cannot be redefined if instances of the class exist.

If a (reset) command is issued, all the instances in memory are deleted and an instance [initial- instance] is created, analogous to the fact, initial-fact.

CLIPS> (reset)
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
For a total of 1 instance.
CLIPS>

Just as (deffacts) defines facts, there is also a definstances to define instances when a (reset) is issued. The following (definstances) also illustrates the optional comment in double quotes after the instance name, DORKY_OBJECTS.

CLIPS>
(definstances DORKY_OBJECTS "The Dorky Cousins"
  (Dorky of DUCK)
  (Dorky_Duck of DUCK))
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
For a total of 1 instance.
CLIPS> (reset)
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky] of DUCK
[Dorky_Duck] of DUCK
For a total of 3 instances.
CLIPS>

Although a (reset) will delete all instances except [initial-instance], it will also make new instances from (definstances). If you want to permanently delete an instance, the function unmake-instance will delete one or all instances, depending on its argument. To delete all instances, use the *.

The following examples illustrate the (unmake-instance) command.

; Delete all instances
CLIPS> (unmake-instance *)
TRUE
; Check that all are gone
CLIPS> (instances)
; Create new instances again
CLIPS> (reset)
; Check new instances created
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky] of DUCK
[Dorky_Duck] of DUCK
For a total of 3 instances.
; Delete a specific instance
CLIPS> (unmake-instance [Dorky])
TRUE
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky_Duck] of DUCK
For a total of 2 instances.
CLIPS>

Another way to delete a specific instance is to send a delete message. The general syntax of the (send) function is as follows.

(send <instance-name> <message>)

For example, the following will make Dorky_Duck disappear.

; Create new instances again
CLIPS> (reset)
; Check new instances created
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky] of DUCK
[Dorky_Duck] of DUCK
For a total of 3 instances.
CLIPS> (send [Dorky_Duck] delete)
TRUE
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky] of DUCK
For a total of 2 instances.
CLIPS>

The * in a (send) will not work to delete all instances. The * only works with the (unmake) function. Another alternative is to define your own handler for delete that will accept the * and thus allow you to (send <instance-name> my_delete *) messages.

A (send) message is acted upon only by a target object which has an appropriate handler. CLIPS automatically provides handlers for print, init, delete and so on for each user-defined class. It's important to realize that the message (send [Dorky_Duck] delete) works only because this instance is a user-defined class. If you define classes which do not inherit from USER such as a subclass of INTEGER, you must also create appropriate handlers to carry out all desired tasks such as printing, creating, and deleting instances. It's much easier to define subclasses of USER and take advantage of system-supplied handlers.

The (send) function is the heart of OOP operation since it is the only proper way for objects to communicate. According to the principle of object encapsulation, one object should only be allowed to access another object's data by sending a message.

For example, if someone wants to know what you had for breakfast, they'll generally ask you, i.e., send a message. An impolite alternative would be to yank open your mouth and peer down your throat. If the principle of object encapsulation is not followed, any object can fool around with the private parts of other objects, with potentially disastrous results.

One useful application of (send) is to print information about an object. So far all the examples of objects that you have seen have no structure. However, just as deftemplate gives structure to a rule pattern, the slots give an object structure. For both deftemplate and objects, a slot is a named location in which data can be stored. However, unlike deftemplate slots, objects obtain their slots from classes, and classes use inheritance. Thus, the information in object slots can be effectively inherited by objects of subclasses. An unbound slot is one that has no values assigned. All slots must be bound.

As a simple example, let's make an object with slots to hold personal information and then send messages to it. The following commands will first set up the CLIPS environment with the appropriate constructs. The slots named sound and age initially contain no data, i.e., nil values.

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (slot sound)
  (slot age))
CLIPS>
(definstances DORK_OBJECTS
  (Dorky_Duck of DUCK))
CLIPS> (reset)
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound nil)
(age nil)
CLIPS> (send [Dorky_Duck] put-sound quack)
quack
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack)
(age nil)
CLIPS>

Notice that the slots are printed in the order defined in the class. However, if the instance inherits slots from more than one class, the slots from the more general classes will be printed first.

The value of a slot is changed using the put- message. By default, CLIPS creates a put- handler for each slot of a class to handle put- messages. Notice the dash, -, at the end of put-. The dash is an essential part of the message syntax since it separates the put from the slot name. Only one put- is allowed in a (send). Thus, to change multiple slots or the same slot of many instances, you must send multiple messages. Instead of doing this manually, it's possible to write a function to do multiple sends, or use the modify-instance function.

The value of a slot can be set by a slot-override in a make-instance. As an example,

CLIPS>
(make-instance Dixie_Duck of DUCK
  (sound quack) (age 2))
[Dixie_Duck]
CLIPS> (send [Dixie_Duck] print)
[Dixie_Duck] of DUCK
(sound quack)
(age 2)
CLIPS>

The complementary message to put- is get- which gets the data from a slot, as shown in the following example. If a put- is successful it returns the new value, while if get- is successful it returns the appropriate data. If the put- or get- does not succeed, an error message will be returned. The following examples show how this works.

; No slot color
CLIPS> (send [Dorky_Duck] put-color white)
[MSGFUN1] No applicable primary message-handlers found for
put-color.
FALSE
CLIPS> (send [Dorky_Duck] get-age)
nil
; Value put in age
CLIPS> (send [Dorky_Duck] put-age 1)
1
; Check value is correct
CLIPS> (send [Dorky_Duck] get-age)
1
CLIPS>

In contrast to the put- message, the get- message returns the value of a slot. Since the value of get- is returned, it can be used by another function, assigned to a variable, and so forth. In contrast, a value that is printed out cannot be used by another function, assigned to a variable, and so forth because the value goes to the standard output device. One way of getting around this problem is to print out to a file and then read in the data from the file. While this is not an elegant solution, it does work. Another way is to write your own print message-handler that also returns values.

A very important point about slots is that you cannot modify the slots of a class by adding slots, deleting slots, or changing the characteristics of slots. The only way to change a class is to (1) delete all instances of the class, and (2) use a (defclass) with the same class name and the desired slots. This situation is analogous to modifying a rule by loading in a new rule with the same name.

There are a number of useful predicate functions for slots. If you use these predicate functions to test for appropriate values to functions, your program will be more robust against crashes. In general, if a function does not return TRUE, it returns FALSE. Slot functions provided by CLIPS include:

• class-slot-exists: Returns TRUE if the class slot exists.
• slot-existp: Returns TRUE if the instance slot exists.
• slot-boundp: Returns TRUE if the specified slot has a value.
• instance-address: Returns the machine address at which the specified instance is stored.
• instance-name: Returns the name given an instance.
• instancep: Returns TRUE if its argument is an instance.
• instance-addressp: Returns TRUE if its argument is an instance address.
• instance-namep: Returns TRUE if its argument is an instance name.
• instance-existp: Returns TRUE if the instance exists.
• list-definstances: Lists all the definstances.
• ppdefinstances: Pretty-prints the definstance.
• watch instances: Allows you to watch instances being created and deleted.
• unwatch instances: Turns off watching instances.
• save-instances: Saves instances to a file.
• load-instances: Loads instances from a file.
• undefinstances: Deletes the named definstance.

The default facet sets the default value of a slot when an instance is created or initialized, as shown in the following example.

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (slot sound (default quack))
  (slot ID)
  (slot sex (default male)))
CLIPS> (make-instance Dorky_Duck of DUCK)
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack)
(ID nil)
(sex male)
CLIPS>

As you can see, the default values for slot sex and slot sound were set by the default facet values. Following the default keyword can be any valid CLIPS expression that does not involve a variable. For example, the default expression of the sound slot is the symbol quack. Functions may be used in the facet expression as will be shown in the next example.

This default facet is a static default because the value of its facet expression is determined when the class is defined and never changed unless the class is redefined. For example, let's set the default value of slot ID to the (gensym*) function which returns a new value not in the system every time it's called.

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (slot sound (default quack))
  (slot ID (default (gensym*)))
  (slot sex (default male)))
CLIPS> ; Dorky_Duck #1
(make-instance [Dorky_Duck] of DUCK)
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack)
(ID gen1)
(sex male)
CLIPS> ; Dorky_Duck #2
(make-instance [Dorky_Duck] of DUCK)
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack)
(ID gen1)
(sex male)
CLIPS>

As you can see, the ID is always gen1 since (gensym*) is only evaluated once, and not again when the second instance is created. Note that the (gensym*) values may be different on your computer if you have already called (gensym*) since it increments by one each time it is called, and is not reset by a (clear). The (gensym*) function is reset to its starting value only if you restart CLIPS.

Now suppose that we want to keep track of the different Dorky_Duck instances that have been created. Rather than using the static default, we can use the facet called default dynamic, which will evaluate its facet expression every time a new instance is created. Notice the difference between the following example and the previous.

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (slot sound (default quack))
  (slot ID (default-dynamic (gensym*)))
  (slot sex (default male)))
CLIPS> ; Dorky_Duck #1
(make-instance [Dorky_Duck] of DUCK)
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack)
(ID gen2)
(sex male)
CLIPS> ; Dorky_Duck #2
(make-instance [Dorky_Duck] of DUCK)
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack)
(ID gen3) ; Note ID is different
(sex male) ; from Dorky_Duck #1
CLIPS>

The cardinality of a slot refers to one of two types of fields that a slot can hold: (1) single-field, or (2) multifield. The term cardinality refers to a count. A bound single-field slot contains only one field, while a bound multifield slot may contain zero or more fields. The bound single-field slot and the bound multifield slot each contain one value. However, the one multifield value may have multiple fields in it. For example, (a b c) is a single multifield value with three fields. The empty string "" is a single-field value, just as "a b c" is. In contrast, an unbound slot has no value.

As an analogy to single and multifield variables, think of a slot as your mailbox. Sometimes you may find a single piece of junk-mail that doesn't have an envelope. Instead, an address label has just been stuck on a folded piece of paper addressed to Resident. Other times you may find an envelope with multiple ads in it. The single piece of junk mail without an envelope is like a single-field value while the envelope with multiple ads is like the multifield value. If the junk-mail distributor slips up and mails you an envelope with nothing inside, this corresponds to the empty multifield variable. (Come to think of it, if the junk-mail envelope is empty, have you really received junk-mail?)

A multiple facet with keyword multislot, is used to store a multifield value as shown in the following example

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (multislot sound (default quack quack)))
CLIPS> (make-instance [Dorky_Duck] of DUCK)
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] print)
[Dorky_Duck] of DUCK
(sound quack quack)
CLIPS>

A multifield value can be accessed using get- and put- as shown in the following examples, which shows how to keep track of quacks.

CLIPS>
(send [Dorky_Duck] put-sound
                   quack1 quack2 quack3)
(quack1 quack2 quack3)
CLIPS> (send [Dorky_Duck] get-sound)
(quack1 quack2 quack3)
CLIPS>

Standard CLIPS functions such as nth$ to get the nth field of a multislot value can be used. The following example shows how to pick a certain quack.

CLIPS> (nth$ 1 (send [Dorky_Duck] get-sound))
quack1
CLIPS> (nth$ 2 (send [Dorky_Duck] get-sound))
quack2
CLIPS> (nth$ 3 (send [Dorky_Duck] get-sound))
quack3
CLIPS>

A create-accessor facet tells CLIPS whether to create put- and get- handlers for a slot. By default, all slots have a read-write create-accessor so you don't actually have to specify this facet to create handlers. If you define your own handlers, then you need to use ?NONE with the create-accessor facet. The other facet types for create accessor are read and write.

A storage facet defines one of two places that a slot value is stored: (1) in an instance, or (2) in the class. A slot value stored in the instance is called local because the value is only known to the instance. Thus, different instances may exist that have different local slot values. In contrast, a slot value stored in a class is called shared because it is the same for all instances of the class.

A local value is specified by the local facet, which is the default for a slot. A shared value is specified by the shared facet and all instances with this slot type will have their slot value automatically changed if one changes.

An access facet defines one of three types of access for a slot, whether you use the handlers created by CLIPS or else define your own. The default type, read-write, allows you to both read and write the value of the slot. The other types are read-only and initialize-only.

Two predicate functions are designed for use with the access facets. Both these predicate functions return an error message if the specified slot or instance does not exist. The slot-writablep is a predicate function which returns TRUE if a slot is writable and FALSE if it is not. The slot-initablep predicate function returns TRUE if the slot is initializable and FALSE if it is not. The term initializable means that it is not read-only.

The inherit facet, which is the default, specifies that indirect instances of a class may inherit this slot from the class. As you recall, the indirect instances of a class are the instances of its subclasses, while the direct instances are those defined specifically for the class. The indirect instances of a class are direct instances of the subclasses in which they are defined. For example, [Dorky_Duck] is a direct instance of DUCK and an indirect instance of USER which is the superclass of DUCK. The no-inherit facet specifies that only a direct instance has the class slot.

It's important to realize that the (no-inherit) facet only prohibits inheritance from the class and not from its superclasses. This means that an instance may still inherit from superclasses of the (no-inherit) class.

The composite facet states that facets which are not explicitly defined in the highest precedence class take their facets from the next higher precedence class. If the facet is not explicitly set in the next higher precedence class and it is composite too, CLIPS tries the next higher and so on until the facet is defined or there are no more classes. If the next higher class is not composite, CLIPS does not check further. The opposite to the composite facet is the exclusive facet, which is the default.

Another way to set the instance values is with the initialize-instance function. An (initialize-instance) can be called at any time to reset the default values and retain values in non- (default) slots.

A (reset) can be thought of as a cold-initialization since all values in non-(default) slots are cleared, while a (initialize-instance) can be considered a warm-initialization since non-(default) values are retained. Of course, only (definstances) can be cold-initialized since non-(definstances) will simply be deleted. Also, slot-overrides may be used in (initialize-instance) as the last example shows.

CLIPS has several multifield slot functions as shown in the following list.

• slot-replace$: Replace the specified range.
• slot-insert$: Insert the specified range.
• slot-delete$: Delete the specified range.

In addition to the predefined handlers such as print, you may define your own handlers. Let's start by writing a handler to add numbers through messages.

The class NUMBER has subclasses INTEGER and FLOAT. Since these are predefined classes, it would seen natural to do numeric calculations by sending messages to numbers. Let's try it as follows.

CLIPS> (clear)
CLIPS> (send 1 + 2)
[MSGFUN1] No applicable primary message-handlers found for +.
FALSE
CLIPS>

Well, as you can see, this example didn't work. The reason why is implied in the error message. Let's check it out by obtaining more information about the INTEGER class since that was the target object of the print message.

CLIPS> (describe-class INTEGER)

The problem is that the INTEGER class has no handler for +. In fact, it has no handlers at all since none are listed. As you recall, the USER class and its subclasses always have print, delete, and other handlers automatically defined by CLIPS. If we want to send print messages to an object like 1 of the INTEGER class, we'll have to write our own print handler.

Before writing this handler, let's answer a question that you may have concerning how INTEGER can have instances. Since INTEGER is an abstract class, you may wonder how it can have instances such as 1, 2, 3, etc. Although you cannot make direct instances of an abstract class, you can make use of existing instances. For the case of the predefined system class INTEGER, all the integers up to the maximum allowed are available as objects. Likewise, strings and symbols are available for the system defined abstract classes STRING and SYMBOL, and so forth for the other predefined classes.

Shown following is the definition of a handler for the NUMBER class that will handle addition by messages. The handler is defined for NUMBER rather than INTEGER because we would also like to handle FLOAT objects too. Instead of defining the same handler for FLOAT and for INTEGER, it's easier to just define a handler for the superclass NUMBER. If a handler for a message is not defined in the class of the object, CLIPS tries all the handlers in the inheritance precedence list. Since + is not defined for INTEGER, CLIPS tries NUMBER next, finds the applicable handler, and returns the result of 3.

CLIPS>
; ?arg is argument of handler
(defmessage-handler NUMBER + (?arg)
  ; Function addition of handler
  (+ ?self ?arg))
CLIPS> (send 1 + 2)
3
CLIPS> (send 2.5 + 3)
5.5
CLIPS> (send 2.5 + 2.6)
5.1
CLIPS> (describe-class NUMBER)
===========================================================
***********************************************************
Abstract: direct instances of this class cannot be created.
Direct Superclasses: PRIMITIVE
Inheritance Precedence: NUMBER PRIMITIVE OBJECT
Direct Subclasses: INTEGER FLOAT
-----------------------------------------------------------
Recognized message-handlers:
+ primary in class NUMBER
***********************************************************
===========================================================
CLIPS>

The variable ?self is a special variable in which CLIPS stores the active instance. The ?self is a reserved word that cannot be explicitly included in a handler argument, nor can it be bound to a different value. The active instance is the instance to which the message was sent. In our example, all the predefined classes such as NUMBER, INTEGER, and FLOAT are all subclasses of the PRIMITIVE class. This is in contrast to USER, which is the other main subclass of OBJECT.

As another example, lets write a handler to concatenate strings, symbols or both.

CLIPS>
; ?arg is argument of handler
(defmessage-handler LEXEME + (?arg)
  ; Function concatenation of handler
  (sym-cat ?self ?arg))
; SYMBOL + STRING
CLIPS> (send Dorky_ + "Duck")
Dorky_Duck ; SYMBOL result
CLIPS>

Notice that the handler is defined for the LEXEME class since that is a superclass of both SYMBOL and STRING. In this case, the handler returns a SYMBOL since (sym-cat) is used.

This example also illustrates why brackets may be necessary in a (send). As shown in this example, the message goes to the SYMBOL Dorky_ without brackets. With brackets, the message goes to an object [Dorky_] of a user-defined class. Here we assume that [Dorky_] could be an object of a user-defined class, such as DUCK.

The real utility of handlers is with subclasses of USER since you can define instances of these classes. To see how handlers work in this case, let's first set up the environment as follows.

CLIPS> (clear)
CLIPS>
(defclass DUCKLING (is-a USER)
  (slot sound (default quack))
  (slot age (visibility public)))
CLIPS>
(defclass DUCK (is-a DUCKLING)
  (slot sound (default quack)))
CLIPS>
(definstances DUCKY_OBJECTS
  (Dorky_Duck of DUCK (age 2))
  (Dinky_Duck of DUCKLING (age .1)))
CLIPS> (reset)
CLIPS>

As a simple example, let's write a handler that will print out the slots of the active instance. We can make use of the ppinstance function to print out the slots of the active instance. This function does not return a value and is used only for its side-effect of printing to the standard device. Also, it can only be used from within a handler since only there is the active instance known. Shown following is a USER-defined handler called print-slots that prints out the slots of the active instance using (ppinstance).

CLIPS>
(defmessage-handler USER print-slots ()
  (ppinstance))
CLIPS> (send [Dorky_Duck] print-slots)
[Dorky_Duck] of DUCK
(age 2)
120(sound quack)
CLIPS>

Although the handler could be defined just for DUCK in this case, a handler defined for USER will be called for all subclasses of USER, not just DUCKLING and DUCK. Thus, the handler print-slots will work for all subclasses that we may define of USER.

Of course it's possible to get carried away and define all your message handlers as USER handlers. However, it's good style and improves efficiency to define handlers as close as possible to the class or classes for which they are intended. Efficiency is improved because CLIPS does not have to keep searching through a lot of classes to find the applicable handler.

Let's examine message-handlers in more detail now. We'll define a handler to print out a header when an object receives a message to print itself. The message-handler is defined using a defmessage-handler construct as follows.

CLIPS>
(defmessage-handler USER print before ()
  (printout t "*** Starting to print ***" crlf))
CLIPS> (send [Dorky_Duck] print)
*** Starting to print ***
[Dorky_Duck] of DUCK
(age 2)
(sound quack)
CLIPS>

The reason that a header is printed rather than a trailer at the end has to do with the handler type. A before type handler is used before the print message. To make a trailer, use the after type handler as shown in the following example.

CLIPS>
(defmessage-handler USER print after ()
  (printout t "*** Finished printing ***" crlf))
CLIPS> (send [Dorky_Duck] print)
*** Starting to print ***
[Dorky_Duck] of DUCK
(age 2)
(sound quack)
*** Finished printing ***
CLIPS>

The general format of a message-handler is as follows.

(defmessage-handler <class-name>
  <message-name> [handler-type]
  [comment]
  (<parameters>* [wildcard-parameter])
  <action>*)

While there may be multiple actions in a handler, only the value of the last action is returned. Notice that this is just like a (deffunction).

Since [Dorky_Duck] is of class DUCK, a subclass of USER, we can take advantage of the print handler that is predefined by CLIPS for the USER class. All subclasses of USER can take advantage of the handlers of USER, which saves you the trouble of writing handlers for every class that you define. Notice how the concept of inheritance from USER to its subclass DUCK simplifies program development by allowing reuse of existing code, i.e., the print handler of USER.

The empty parentheses () that follow the before handler type mean that there are neither parameters nor a wildcard parameter. In other words, the header handler takes no arguments and so the parentheses are empty, but required. Note that while multiple parameters may be used, there can be only one wildcard.

As you can see, the trailer handler is the same as the header handler except that an after handler type is used, and the action text is different. Thus, a before handler type does its task before the primary type handler, and an after handler does its task after the primary handler. A primary is intended to do the major task. An around handler type is intended to set up the environment for the rest of the handlers. The before and after types are intended for minor tasks such as initializing variables or printing, while the primary does the major task.

The following list summarizes the class role and return value of each handler type:

• around: Set up environment for other handlers. Returns a value.
• before: Auxillary work before primary. No return value.
• primary: Perform major task of message. Returns a value.
• after: Auxillary work after primary. No return value.

The handler types are listed in the order that they are normally called during execution of a message. Depending on the handler type, CLIPS knows when to execute it. That is, an around handler starts before any before handlers. A before handler is executed before any primary handlers, which are followed by the after handlers. The exception to this sequential handler execution is the around type handler. If an around handler is defined, it will start execution before any of the others, perform specified actions, and then complete its actions after all the other handler types have finished. You'll see a detailed example of these handlers execution soon.

The class role describes the intended purpose of each type. The return value describes whether the handler type is generally intended for a return value or simply to provide a useful side-effect such as printing. This consideration will depend on the handler. For example, many user-defined primary handlers may be written to return a value as the result of some numeric calculation or string operation. An exception to returning a useful return value is a print primary handler whose main task is the side-effect of printing, and does not have a return value.

The list of predefined primary handlers of USER and their class role is shown following. By inheritance, these are available for all subclasses of USER.

• init: Initializes an instance.
• delete: Deletes an instance.
• print: Prints an instance.
• direct-modify: Directly modifies slots.
• message-modify: Modifies slots using put- messages.
• direct-duplicate: Duplicates an instance without using put- messages.
• message-duplicate: Duplicates an instance using messages.

These primary handlers are predefined and cannot be modified unless you change the source code of CLIPS. However, you may define the before, after and around handler types for these primaries. You've already seen an example of changing the before and after handler types for the USER print handler. Now let's look at some examples of defining the before and after handler types for the init primary handler.

CLIPS>
(defmessage-handler USER init before ()
  (printout t "*** Starting to make instance ***" crlf))
CLIPS>
(defmessage-handler USER init after ()
  (printout t "*** Finished making instance ***" crlf))
CLIPS> (reset)
*** Starting to make instance ***
*** Finished making instance ***
*** Starting to make instance ***
*** Finished making instance ***
*** Starting to make instance ***
*** Finished making instance ***
CLIPS> (make-instance Dixie_Duck of DUCK (age 1))
*** Starting to make instance ***
*** Finished making instance ***
[Dixie_Duck]
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Dorky_Duck] of DUCK
[Dinky_Duck] of DUCKLING
[Dixie_Duck] of DUCK
For a total of 4 instances.
CLIPS>

The self parameter is useful because it can be used to read a slot value in the form

?self:<slot-name>

It can also be used to write a slot value using the bind function. The ?self: notation is more efficient than sending messages but can only be used from within a handler on its active instance.

In contrast, the dynamic-get- and dynamic-put- functions can be used from within a handler to read and write a slot value of the active instance. Although you can use messages from inside a handler, such as the following, it's not efficient.

(send ?self dynamic-get-<slot>)
(send ?self dynamic-put-<slot>)

As an example of dynamic-get-, let's change our example as follows.

CLIPS>
(defmessage-handler USER print-age primary ()
  (printout t "*** Starting to print ***" crlf
   "Age = " (dynamic-get age) crlf
   "*** Finished printing ***" crlf))
CLIPS> (send [Dorky_Duck] print-age)
*** Starting to print ***
Age = 2
*** Finished printing ***
CLIPS>

The ?self:age can only be used in a class and its subclasses which inherit the slot age. The ? self:<slot-name> is evaluated in a static way through inheritance. This means that if a subclass redefines a slot, a superclass message-handler will fail if it tries to directly access the slot using ? self:<slot-name>.

In contrast, the dynamic-get- and dynamic-put- can be used by superclasses and subclasses because these check slots dynamically. In order for a superclass to dynamically reference a slot, however, the visibility facet of the slot must be public. The following example would not work if DUCK is changed to USER.

CLIPS>
(defmessage-handler DUCK print-age primary ()
  (printout t "*** Starting to print ***" crlf
  "Age = " ?self:age crlf
  "*** Finished printing ***" crlf))
CLIPS> (send [Dorky_Duck] print-age)
*** Starting to print ***
Age = 2
*** Finished printing ***
CLIPS>

As an example of using a dynamic-put- function in a handler, suppose we want to help Dorky_Duck regain some of his youth. The following example shows how his age can be changed using a handler. This example also illustrates how a value can be passed to a handler through the ?change variable.

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (slot sound (default quack))
  (slot age))
CLIPS>
(defmessage-handler DUCK lie-about-age
  (?change)
  (bind ?new-age (- ?self:age ?change))
  (dynamic-put age ?new-age)
  (printout t "*** Starting to print ***" crlf
  "I am only " ?new-age crlf
  "*** Finished printing ***" crlf))
CLIPS>
(make-instance [Dorky_Duck] of DUCK (age 3))
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] lie-about-age 2)
*** Starting to print ***
I am only 1
*** Finished printing ***
CLIPS>

Notice how the handler uses the variable ?new-age to store the changed age, which is then put into the age slot of the instance.

A daemon is a handler which executes whenever some basic action like initialization, deletion, get, or put is performed on an instance. A rule cannot be considered a daemon because it's not certain that it will be executed just because its LHS patterns are satisfied. The only thing that is certain is that a rule will become activated when its LHS is satisfied — not that it will execute.

There is no explicit keyword for daemon since it's just a concept. The before and after handlers that printed strings can be considered print daemons. These handlers waited for a (send [Dorky_Duck] print-age) message to trigger their action. First the before handler printed its string, then the primary handler printed, and finally the after handler printed. One daemon is the before handler which waits for a print message. The second daemon is the after handler that waits for the print primary to finish printing.

Printing is not considered a basic action because there is no return value associated with a (send <instance> print). The print message is only sent for the side-effect of printing. In contrast, a (send <instance> get-<slot>) message will return a value that may be used by other code. Likewise, the initialization, deletion, and put all have an effect on an instance and so are considered basic actions like get.

Daemons are easily implemented using before and after handlers since these will be executed before and after their primary handler. Implementing daemons like this is called declarative implementation because no explicit actions on the part of the handler is necessary for it to be executed. That is, CLIPS will always execute a before handler before its primary and will always execute an after handler after its primary. In a declarative daemon implementation, the normal operation of CLIPS will cause the daemons to be activated when their time has come. Thus, the declarative implementation is implicit in the normal operation.

The opposite of implicit execution is the imperative implementation in which the actions are explicitly programmed. The around handler is very convenient to use for imperative daemons. The basic idea of the around handler is as follows.

• 1. Start before any other handlers.
• 2. Call the next handler using either call-next-handler to pass the same arguments or override-next-handler to pass different ones.
• 3. Continue execution when the last handler finishes.
• 4. After any other around, before, primary, or after handlers finish, the around handler resumes execution.

The keyword call-next-handler is used to call the next handler(s). A handler is said to be shadowed by a shadower if it must be called from the shadower by a function such as call-next-handler. The call-next-handler may be used multiple times to call the same handler(s).

A predicate function called next-handlerp is used to test for the existence of a handler before the call is made. If no handler exists, then next-handlerp will return FALSE.

The following example illustrates the around handler through a truthful daemon that tells on Dorky_Duck whenever he lies about his age.

CLIPS>
(defmessage-handler DUCK lie-about-age around
  (?change)
  (bind ?old-age ?self:age)
  (if (next-handlerp) then
    (call-next-handler))
  (bind ?new-age ?self:age)
  (if (<> ?old-age ?new-age) then
    (printout t "Dorky_Duck is lying!" crlf
                "Dorky_Duck is lying!" crlf
                "He's really " ?old-age crlf)))
CLIPS>
(make-instance [Dorky_Duck] of DUCK (age 3))
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] lie-about-age 1)
*** Starting to print ***
I am only 2
*** Finished printing ***
Dorky_Duck is lying!
Dorky_Duck is lying!
He's really 3
CLIPS>

Although Dorky_Duck may still lie about his age, the daemon tells the truth. Notice the ?change argument. Although the around handler does not use ?change, the lie-about-age primary that is called by the call-next-handler does need it to change the age. Thus, ?change must be passed to the primary by the around handler. An error message will occur if you leave out the ?change.

The call-next-handler always passes the arguments of the shadower to the shadowed handler. It's possible to pass different arguments to a shadowed handler by use of the override-next-handler function as shown i n the following example.

CLIPS>
(defmessage-handler DUCK lie-about-age around
  (?change)
  (bind ?old-age ?self:age)
  (if (next-handlerp) then
    ; Divide age in half!
    (override-next-handler (/ ?change 2)))
  (bind ?new-age ?self:age)
  (if (<> ?old-age ?new-age) then
    (printout t "Dorky_Duck is lying!" crlf
                "Dorky_Duck is lying!" crlf
                "He's really " ?old-age crlf)))
CLIPS>
(make-instance [Dorky_Duck] of DUCK (age 3))
[Dorky_Duck]
CLIPS> (send [Dorky_Duck] lie-about-age 1)
*** Starting to print ***
I am only 2.5
*** Finished printing ***
Dorky_Duck is lying!
Dorky_Duck is lying!
He's really 3
CLIPS>

Shown following are the Rules of Message Dispatch:

• 1. All the around handlers start execution. Then the before, primary, and after handlers start and finish, followed by completion of the around's execution.
• 2. The around, before, and primary handlers are called in order of highest precedence class to lowest.
• 3. The after handlers are called from lower precedence class to highest.
• 4. Each around handler must explicitly call the next shadowed handler.
• 5. Higher precedence primaries must explicitly call lower precedence (shadowed) primaries if they are to execute.

However, note the following prerequisite to any message handling:

There must be at least one applicable primary handler.

Since only around and primary handlers can return values, and the around shadows primaries, it follows that the return value of a (send) will be the around return value. If there is no around, then the return value will be that of the highest precedence primary.

The following list summarizes the return value of the handler types.

• around: Ignore or capture return value of next most specific around or primary.
• before: Ignore. Side-effect only.
• primary: Ignore or capture return value of most general primary scope.
• after: Ignore. Side-effect only.

Up to now, we've discussed inheritance using only is-a links. As you've seen, this type of inheritance relationship is good for defining classes that are more and more specialized. That is, you start off by defining the most general classes as a subclass of USER, and then define more specialized classes with more slots in the lower levels of the class hierarchy.

Normally, you design new classes as specializations of existing ones. This paradigm is Inheritance by Specialization.

Inheritance can also be used to build up more complex classes. However, this is not quite as direct in CLIPS. As an example, the basic class for geometry is a POINT containing a single slot point1. A LINE can be then defined by adding point2 to POINT. A TRIANGLE is defined by adding point3 to LINE, and so on for QUADRILATERALS, PENTAGONS, etc.

(defclass POINT (is-a USER)
  (multislot point1))
(defclass LINE (is-a POINT)
  (multislot point2))
(defclass TRIANGLE (is-a LINE)
  (multislot point3))

Notice how each class is a specialization of its parent class by inheriting the superclass points and then adding one new point.

The opposite paradigm is Inheritance by Generalization in which more general classes are built up from simple ones. For example, a LINE is considered made up of two points. A TRIANGLE is made up of three lines. A QUADRILATERAL is made up of four lines, and so forth. This would be a good paradigm for building an object-oriented drawing system in which new objects could be built up out of simpler ones.

Notice how each class is a specialization of its parent class by inheriting the superclass points and then adding one new point.

The opposite paradigm is Inheritance by Generalization in which more general classes are built up from simple ones. For example, a LINE is considered made up of two points. A TRIANGLE is made up of three lines. A QUADRILATERAL is made up of four lines, and so forth. This would be a good paradigm for building an object-oriented drawing system in which new objects could be built up out of simpler ones.

There is a subtle but important difference between this example of specialization, and generalization. In specialization, new classes are built up by adding specialized slots which are the same type as superclass slots. Thus, POINT, LINE, and TRIANGLE all have point-type slots. In contrast, generalization builds up using new types of slots defined for each class. Class POINT has a point-type slot. LINE has two point-type slots. TRIANGLE has three line-type slots. QUADRILATERAL has four line-type slots, and so on. Generalization is good for synthesis, which means a building up. The opposite of synthesis is analysis, which means taking apart or a simplification. The model for analysis is specialization.

Links such as is-made-of can be simulated in CLIPS by appropriate slot definitions even though only is-a links are supported in Version 6.3. As an example of generalization, let's build up a LINE class as a generalization of a POINT class. The POINT class will provide instances that have a position. In order to make this example realistic, we'll assume an arbitrary number of dimensions by defining the position as (multiple). Thus, a one-dimensional point will have one value in the position slot, a two-dimensional point will have two values, and so forth. The definition of the POINT class is very simple.

CLIPS> (clear)
CLIPS>
(defclass POINT (is-a USER)
  (multislot position
            (propagation no-inherit)
  )
)
CLIPS>

The (no-inherit) facet is used to prevent a LINE from inheriting a position slot. Instead, a LINE will be defined by two points called slot point1 and slot point2. These two slots will define the line and it is extraneous to have an additional position slot by inheritance.

The definition of the LINE class is a little more complex. The reason for the added complexity is that the details of implementation are included in the (defclass) because Version 6.3 only supports is-a relationships.

(defclass LINE (is-a POINT)
  (slot point1
    (default-dynamic
      (make-instance (gensym*) of POINT))
    (propagation no-inherit))
  (slot point2
    (default-dynamic
      (make-instance (gensym*) of POINT))
  (propagation no-inherit))
(message-handler find-point)
(message-handler print-points)
(message-handler find-distance)
(message-handler print-distance))

Note that the message-handlers of LINE are forward-declared for documentation purposes.

At this time you may be wondering why POINT and LINE are not both defined as subclasses of USER since all their slots have (no-inherit) facets. Since all the slots of POINT, LINE, and the TRIANGLE class to be defined later have (no-inherit) facets, all these classes could be defined as direct subclasses of USER rather than defining LINE as a subclass of POINT and TRIANGLE as a subclass of LINE.

However, the whole point of this example is to illustrate Inheritance by Generalization, which is a logical concept that is not directly supported by Version 6.3. Thus, defining LINE as a subclass of POINT and TRIANGLE as a subclass of LINE is done for reasons of documenting the logical concept of Inheritance by Generalization. Admittedly, a comment could be added by the (defclass LINE (is-a USER)) and (defclass TRIANGLE (is-a USER)) stating that we are trying to implement Inheritance by Generalization, but seeing the code in place is better documentation. If Inheritance by Generalization is ever directly supported by CLIPS, these (defclass) statements will make it easy to convert.

The reason for including the (make-instance (gensym*)) in the LINE slots is to provide the inheritance from the POINT class. With the standard Inheritance by Specialization, only one position slot of LINE is possible because POINT has only one position slot. It is not possible for both slot point1 and slot point2 of LINE to inherit the position slot of POINT. The actual slot value of each LINE will be a gensym* value. Each gensym* value will be the instance name of a point instance. The point position can then be accessed through the gensym* value. Thus, the gensym* values act as pointers to different instances.

This indirect access technique of (gensym*) values is analogous to using a pointer to access a value in a procedural language. Thus, the different slots of LINE can indirectly inherit the same slots of POINT. It's convenient to use (gensym*) because we don't care what the pointer names of LINE are, any more than we care what the pointer addresses are in a procedural language.

The following examples show how the points are accessed for one-dimensional points at position 0 and 1.

CLIPS>
(definstances LINE_OBJECTS
  (Line1 of LINE))
CLIPS> (reset)
CLIPS>
(send (send [Line1] get-point1)
       put-position 0)
(0)
CLIPS>
(send (send [Line1] get-point2)
       put-position 1)
(1)
CLIPS> (send [Line1] print)
[Line1] of LINE
(point1 [gen1])
(point2 [gen2])
CLIPS>
(send (send [Line1] get-point1)
       get-position)
(0)
CLIPS>
(send (send [Line1] get-point2)
       get-position)
(1)
CLIPS>

Now that you understand how the indirect access works, let's define some handlers to avoid the trouble of entering the nested (send) messages, as in the last two cases. Let's define a handler called find-point to print out a specified point value, and a handler called print-points to print out the values of both LINE points as follows. The argument of find-point will be either a 1 for point1 or a 2 for point2.

CLIPS>
(defmessage-handler LINE find-point (?point)
  (send (send ?self (sym-cat "get-point" ?point))
  get-position))
CLIPS>
(defmessage-handler LINE print-points ()
  (printout t "point1 " (send ?self find-point 1) crlf
              "point2 " (send ?self find-point 2) crlf))
CLIPS> (send [Line1] find-point 1)
(0)
CLIPS> (send [Line1] find-point 2)
(1)
CLIPS>

For real use, it would be best to provide error detection so that only a 1 or 2 is allowed.

As you can see, the handler works fine for one-dimensional points. It can be tested for two-dimensional points as follows. We'll assume the first number for each point is the X-value, and the second number is the Y-value. That is, point1 has X-value 1 and Y-value 2.

CLIPS>
(send (send [Line1] get-point1)
  put-position 1 2)
(1 2)
CLIPS>
(send (send [Line1] get-point2)
  put-position 4 6)
(4 6)
CLIPS> (send [Line1] print)
[Line1] of LINE
(point1 [gen1])
(point2 [gen2])
CLIPS>
(send (send [Line1] get-point1) get-position)
(1 2)
CLIPS>
(send (send [Line1] get-point2) get-position)
(4 6)
CLIPS>

As expected, the handler also works correctly for two-dimensional points.

Now that we have the two point positions, it's easy to find the distance between the points, which is the length of the line. The distance can be determined by defining a new handler called find-distance which uses the Pythagorean Theorem to calculate the distance as the square root of the sum of the squares. Since no assumptions were made as to the number of dimensions, the (nth) function is used to pick out each multifield value up to the maximum number of coordinates, as stored in the ?len variable.

CLIPS>
(defmessage-handler LINE find-distance ()
  (bind ?sum 0)
  (bind ?index 1)
  (bind ?len (length (send ?self find-point 1)))
  (bind ?Point1 (send ?self find-point 1))
  (bind ?Point2 (send ?self find-point 2))
  (while (<= ?index ?len)
    (bind ?dif (- (nth ?index ?Point1)
                  (nth ?index ?Point2)))
    (bind ?sum (+ ?sum (* ?dif ?dif)))
    (bind ?index (+ ?index 1)))
  (bind ?distance (sqrt ?sum)))
CLIPS>
(defmessage-handler LINE print-distance ()
  (printout t "Distance = "
              (send ?self find-distance) crlf))
CLIPS> (send [Line1] print-distance)
Distance = 5.0
CLIPS>

The values 1, 2 for point1 and 4, 6 for point2 were chosen for an easy check of the handler since these coordinates define a 3–4–5 triangle. As you can see, the distance is 5.0, as expected.

Now that the POINT and LINE classes have been defined by generalized inheritance, why stop now? Let's continue with the next simplest class that can be defined from a line — the triangle. Shown following are the three defclasses required.

CLIPS> (clear)
CLIPS>
(defclass POINT (is-a USER)
  (multislot position (propagation no-inherit)))
CLIPS>
(defclass LINE (is-a POINT)
  (slot point1 (default-dynamic
               (make-instance (gensym*) of POINT))
               (propagation no-inherit))
(slot point2 (default-dynamic
             (make-instance (gensym*) of POINT))
             (propagation no-inherit)))
CLIPS>
(defclass TRIANGLE (is-a LINE)
  (slot line1 (default-dynamic
              (make-instance (gensym*) of LINE))
              (propagation no-inherit))
  (slot line2 (default-dynamic
              (make-instance (gensym*) of LINE))
              (propagation no-inherit))
  (slot line3 (default-dynamic
              (make-instance (gensym*) of LINE))
              (propagation no-inherit)))
CLIPS>

Notice that the (no-inherit) facets in TRIANGLE are technically not necessary since there is no subclass of TRIANGLE defined. The reason for including the (no-inherit) facets is because of defensive-programming, which is analogous to defensive-driving. If another subclass is added, either by you or someone else, the (defclass) of TRIANGLE must be modified to include the (no-inherit) facets. This is bad style because it means that existing, debugged code must be modified. If you're going to enhance existing, debugged code, you shouldn't have to modify it. It's better to plan ahead for enhancements.

Next we'll define a triangle instance and check the instances generated. Note that your gen values may be different from those shown unless you've just started or restarted CLIPS, or have not used (gensym*) or (gensym) since you started.

CLIPS>
(definstances TRIANGLE_OBJECTS
  (Triangle1 of TRIANGLE))
CLIPS> (reset)
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[Triangle1] of TRIANGLE
[gen3] of LINE
[gen4] of POINT
[gen5] of POINT
[gen6] of LINE
[gen7] of POINT
[gen8] of POINT
[gen9] of LINE
[gen10] of POINT
[gen11] of POINT
For a total of 11 instances.
CLIPS>

At first you may be surprised at all the gensym* values created. However, all of them are necessary. First, gen3 was created for slot line1, which required gen4 and gen5 for the slots point1 and point2 associated with it by inheritance. Second, gen6 was created for slot line2, which required gen7 and gen8 for its slots point1 and point2. Finally, gen9 was created for slot line3, which required gen10 and gen11 for the slots point1 and point2 associated with it . The slots for [Triangle1] and one of its pointer values, [gen3], is shown following.

CLIPS> (send [Triangle1] print)
[Triangle1] of TRIANGLE
(line1 [gen3])
(line2 [gen6])
(line3 [gen9])
CLIPS> (send [gen3] print)
[gen3] of LINE
(point1 [gen4])
(point2 [gen5])
CLIPS>

Now lets put in the X, Y coordinates of [Triangle1] as follows.

CLIPS>
(send (send (send [Triangle1] get-line1)
            get-point1)
      put-position -1 0)
(-1 0)
CLIPS>
(send (send (send [Triangle1] get-line1)
            get-point2)
      put-position 0 2)
(0 2)
CLIPS>
(send (send (send [Triangle1] get-line2)
            get-point1)
      put-position 0 2)
(0 2)
CLIPS>
(send (send (send [Triangle1] get-line2)
            get-point2)
      put-position 1 0)
(1 0)
CLIPS>
(send (send (send [Triangle1] get-line3)
            get-point1)
      put-position 1 0)
(1 0)
CLIPS>
(send (send (send [Triangle1] get-line3)
            get-point2)
      put-position -1 0)
(-1 0)
CLIPS>

The stored values are as follows.

CLIPS> (send [Triangle1] print)
[Triangle1] of TRIANGLE
(line1 [gen3])
(line2 [gen6])
(line3 [gen9])
CLIPS> (send [gen3] print)
[gen3] of LINE
(point1 [gen4])
(point2 [gen5])
CLIPS> (send [gen4] print)
[gen4] of POINT
(position -1 0)
CLIPS> (send [gen5] print)
[gen5] of POINT
(position 0 2)
CLIPS>

As you can see, the line1 pointer [gen1] points to point1 and point2 with their pointers [gen2] and [gen3]. These last two pointers finally point to the actual values of (-1 0) and (0 2) that define line1 of [Triangle1]. It's analogous to Long John Silver finding a treasure chest with a map, [gen1], which leads to another chest with two maps, [gen2] and [gen3], which lead to the two buried treasures at the locations specified by [gen2] and [gen3].

The values stored for each line of [Triangle1] can be retrieved by a single command using nested messages such as the following.

(send (send (send [Triangle1] get-line1)
                                                 get-point1)
                                           get-position)

Although these commands work, it's not much fun to type them in unless you get paid by the hour and need the typing practice. As you might have guessed from the LINE handlers that we defined in the previous section, it's possible to define TRIANGLE handlers as follows.

CLIPS>
(defmessage-handler TRIANGLE find-line-point
  (?line ?point)
  (send (send (send ?self
                    (sym-cat "get-line"
                             ?line))
              (sym-cat "get-point" ?point))
        get-position))
CLIPS>
(defmessage-handler TRIANGLE print-line
  (?line)
  (printout t "point1 "
              (send ?self find-line-point
                          ?line 1)
              crlf
              "point2 "
              (send ?self find-line-point
                          ?line 2)
              crlf))
CLIPS> (send [Triangle1] print-line 1)
point1 (-1 0)
point2 (0 2)
CLIPS>

Using these handlers is a lot more convenient than typing in the nested messages.

At this point, you might be tempted to define a handler called find-line which returns both point values of the specified line. Recall that find-line-point requires the specification of both the line and one of the two points which define the line. So why not just send two messages in the same handler to return both point values of the specified line? Shown following is the handler for find-line and what it returns for line1 of [Triangle1]

CLIPS>
(defmessage-handler TRIANGLE find-line (?line)
  (send (send (send ?self
                    (sym-cat "get-line" ?line))
              get-point1)
        get-position)
  (send (send (send ?self
                    (sym-cat "get-line" ?line))
              get-point2)
        get-position))
CLIPS> (send [Triangle1] find-line 1)
(0 2)
CLIPS>

As you can see, the handler only returns the last message value of (0 2). Thus, the first value of (-1 0) is not returned by CLIPS. This is like the case of deffunctions which only return the last action. One way of getting around this problem and returning both point values of the line is shown following.

CLIPS>
(defmessage-handler TRIANGLE find-line (?line)
  (create$ (send (send (send ?self
                             (sym-cat "get-line" ?line))
                       get-point1)
                 get-position)
           (send (send (send ?self
                             (sym-cat "get-line" ?line))
                       get-point2)
                 get-position)))
CLIPS> (send [Triangle1] find-line 1)
(-1 0 0 2)
CLIPS>

Notice that the (create$) function was used to combine both point values into a single multifield value (-1 0 0 2) which was then returned.

A number of other functions are useful with handlers. Some of these follow.

• undefmessage-handler: Deletes a specified handler.
• list-defmessage-handlers: Lists the handlers.
• delete-instance: Operates on the active handler.
• message-handler-existp: Returns TRUE if handler exists, else FALSE.

The grouping functions group COOL items into a multifield variable.

• get-defmessage-handler-list: Groups the class names, message names, and types (direct or inherited).
• class-superclasses: Groups all superclass names (direct or inherited).
• class-subclasses: Groups all subclass names (direct or inherited).
• class-slots: Groups all slot names (explicitly define or inherited).
• slot-existp: Returns TRUE if the class slot exists, else FALSE.
• slot-facets: Groups the specified slot facet values of a class.
• slot-sources: Groups the slot names of classes which contribute to a slot in the specified class.

The preview-send function is useful in debugging since it displays the sequence of all handlers that potentially may be involved in processing a message. The reason for the term potentially is that shadowed handlers will not be executed if the shadower does not use call-next-handler or override-next-handler.

Handlers are arranged in a message-handler precedence which determines how they are called. The process of determining which handlers should be called and in what order is called the message dispatch. Every time a message is sent to an object, CLIPS arranges the message dispatch for the applicable handlers of that object, which can be viewed by the (preview-send) command. The applicable handlers are all handlers in all classes along the object's inheritance path that may respond to the type of message. Other functions useful with pattern matching objects by rules follow.

• object-pattern-match-delay: Delay pattern matching of rules until after instances are created, modified, or deleted.
• modify-instance: Modifies instance using slot overrides. Object pattern matching delayed until after modifications.
• active-modify-instance: Change the values of the instance concurrent with object pattern matching with direct-modify message.
• message-modify-instance: Change the values of the instance. Delay object pattern matching until all slots are changed.
• active-message-modify-instance: Changes the values of the instance concurrent with object pattern matching using message-modify.

One of the new features of Version 6.0 is the ability of rules to pattern match on objects. The following example shows how the value of the slot sound is pattern matched by a rule.

CLIPS> (clear)
CLIPS>
(defclass DUCK (is-a USER)
  (multislot sound (default quack quack)))
CLIPS>
(make-instance [Dorky_Duck] of DUCK)
[Dorky_Duck]
CLIPS>
(make-instance [Dinky_Duck] of DUCK)
[Dinky_Duck]
CLIPS>
(defrule find-sound
  ?duck <- (object (is-a DUCK)
                   (sound $?find))
=>
  (printout t "Duck "
              (instance-name ?duck)
              " says " ?find crlf))
CLIPS> (run)
Duck [Dinky_Duck] says (quack quack)
Duck [Dorky_Duck] says (quack quack)
CLIPS>

The object-pattern conditional element object is followed by the classes and slots to be matched against. Following the is-a and the slot-name can be constraint expressions involving ?, $?, &, and |.

In addition, instance names can be specified for pattern matching. The following example shows how only one instance of the DUCK class is matched using the name constraint, name, of instances. Note that name is a reserved word and cannot be used as a slot name.

CLIPS>
(defrule find-sound
  ?duck <- (object (is-a DUCK)
                   (sound $?find)
                   (name [Dorky_Duck]))
=>
  (printout t "Duck "
              (instance-name ?duck)
              " says " ?find crlf))
CLIPS> (run)
Duck [Dorky_Duck] says (quack quack)
CLIPS>

Consider the following general type of problem. Given some instances, how many satisfy a specified condition? For example, shown following are the defclasses and definstances of Joe's Home showing the various types of sensors and the appliances connected to them. Notice that an abstract class DEVICE is defined since both SENSOR and APPLIANCE inherit common slots type and location.

CLIPS> (clear)
CLIPS>
(defclass DEVICE (is-a USER)
  (role abstract)
  ; Sensor type
  (slot type (access initialize-only))
  ; Location
  (slot loc (access initialize-only)))
CLIPS>
(defclass SENSOR (is-a DEVICE)
  (role concrete)
  (slot reading)
  ; Min reading
  (slot min (access initialize-only))
  ; Max reading
  (slot max (access initialize-only))
  ; SEN. APP.
  (slot app (access initialize-only)))
CLIPS>
(defclass APPLIANCE (is-a DEVICE)
  (role concrete)
  ; Depends on appliance
  (slot setting)
  ; off or on
  (slot status))
CLIPS>
(definstances ENVIRONMENT_OBJECTS
  (T1 of SENSOR
    (type temperature)
    (loc kitchen)
    (reading 110) ; Too hot
    (min 20)
    (max 100)
    (app FR))
  (T2 of SENSOR
    (type temperature)
    (loc bedroom)
    (reading 10) ; Too cold
    (min 20)
    (max 100)
    (app FR))
  (S1 of SENSOR
    (type smoke)
    (loc bedroom)
    (reading nil) ; Bad sensor nil reading
    (min 1000)
    (max 5000)
    (app SA))
  (W1 of SENSOR (type water)
    (loc basement)
    (reading 0)
    ; OK
    (min 0)
    (max 0)
    (app WP))
  (FR of APPLIANCE
    (type furnace)
    (loc basement)
    (setting low) ; low or high
    (status on))
  (WP of APPLIANCE
    (type water_pump)
    (loc basement)
    (setting fixed)
    (status off))
  (SA of APPLIANCE
    (type smoke_alarm)
    (loc basement)
    (setting fixed)
    (status off)))
CLIPS>

Suppose the following questions or queries are asked. What are all the objects in the database? How are all the objects arranged? What are the relationships between objects? What are all the devices? What are all the sensors? What are all the appliances? Which sensor is connected to which appliance? Are there any sensors whose type is temperature? What sensors of type temperature have a reading between min and the max? An even more basic query is whether or not there are any sensors present.

The query system of COOL is a set of six functions that may be used for pattern matching an instance-set and performing actions. An instance-set is a set of instances, such as the instances of SENSOR. The instances in the instance-set may come from multiple classes that do not have to be related. In other words, the classes do not have to be from the same inheritance path.

The following list from the CLIPS Reference Manual, summarizes the predefined query functions that may be used for instance-set access.

• any-instancep: Determines if one or more instance-sets satisfy a query.
• find-instance: Returns the first instance-set that satisfies a query.
• find-all-instances: Groups and returns all instance-sets which satisfy a query.
• do-for-instance: Performs an action for the first instance-set which satisfies a query.
• do-for-all-instances: Performs an action for every instance-set which satisfies a query as they are found.
• delayed-do-for-all-instances: Groups all instance-sets which satisfy a query and then iterates an action over this group.

The any-instancep function is a predicate function that returns TRUE if there is an instance matching the pattern and FALSE otherwise. Shown following is an example of this query function used with the SENSOR and APPLIANCE classes and instances. The query function determines if there is any instance in the SENSOR class.

CLIPS> (reset)
CLIPS> (instances)
[initial-object] of INITIAL-OBJECT
[T1] of SENSOR
[T2] of SENSOR
[S1] of SENSOR
[W1] of SENSOR
[FR] of APPLIANCE
[WP] of APPLIANCE
[SA] of APPLIANCE
For a total of 8 instances.
; Function returns TRUE because
; there is a SENSOR instance
CLIPS> (any-instancep ((?ins SENSOR)) TRUE)
TRUE
; Evaluation error—Bad!
; No DUCK class
CLIPS> (any-instancep ((?ins DUCK)) TRUE)
[PRNTUTIL1] Unable to find class DUCK.
CLIPS>

The basic format of a query function involves an instance-set-template to specify the instances and their classes, an instance-set-query as the boolean condition that the instances must satisfy, and actions to specify the actions to be taken. The predicate function class-existp returns TRUE if the class exists and FALSE otherwise.

The combination of instance name followed by the one or more class restrictions is called an instance-set-member-template. The query functions may generally be used like any other function in CLIPS.

There are two steps involved in trying to satisfy a query. First, CLIPS generates all the possible instance-sets that match the instance-set-template. Second, the boolean instance-set- query is applied to all the instance-sets to see which ones, if any, satisfy the query. Instance-sets are generated by a simple permutation of the members in a template, where the rightmost members are varied first. Note that a permutation is not the same as a combination because order matters in a permutation but not in a combination.

The function find-all-instances returns a multifield value of all instances which satisfy the query, or an empty multifield value for none. The do-for-instance query function is similar to find-instance except that it performs a single distributed action when the query is satisfied. The do-for-all-instances function is similar to the do-for-instance except that it performs its actions for every instance-set that satisfies the query.

In contrast to rules which are only activated when their patterns are satisfied, deffunctions are explicitly called and then executed. Just because a rule is activated does not mean it will be executed. Deffunctions are completely procedural in nature because once called by name, their code is executed in a procedural manner, statement by statement. Also, no pattern matching involving constraints is used in a deffunction to decide if its actions should be executed. Instead, any arguments that match the number expected by the deffunction argument list will satisfy the deffunction and cause its actions to be executed.

The basic idea of deffunctions as named procedural code is carried to a much greater degree with defgenerics and the defmethods that describe their implementation. A defgeneric is like a deffunction but much more powerful because it can do different tasks depending on its argument constraints and types. The ability of a generic function to perform different actions depending on the classes of its arguments is called overloading the function name.

By proper use of operator overloading, it's possible to write code that is more readable and reusable. For example, a defgeneric for the + function can be defined with different defmethods. The expression,

(+ ?a ?b)

could add two real numbers represented by ?a and ?b, or two complex numbers, or two matrices, or concatenate two strings, and so forth depending if there is a defmethod defined for the argument classes. CLIPS does this by first recognizing the type of the arguments and then calling the appropriate defmethod defined for those types. A separate overloaded defmethod for + would be defined for each set of argument types except for the predefined system types such as real numbers. Once the defgeneric is defined, it's easy to reuse in other programs.

Any named function that is system defined or external can be overloaded using a generic function. Notice that a deffunction cannot be overloaded. An appropriate use of a generic function is to overload a named function. If overloading is not required, you should define a deffunction or an external function.

The syntax of defgenerics is very simple, consisting of just the legal CLIPS symbol name and an optional comment.

(defgeneric <name> [<comment>])

As a simple example of generic functions, consider the following attempt in CLIPS to compare two strings using the > function.

CLIPS> (clear)
CLIPS> (> "duck2" "duck1")
[ARGACCES5] Function > expected argument #1 to be of type
integer or float
CLIPS>

It's not possible to do this comparison with the > function because it expects NUMBER types as arguments.

However, it's easy to define a (defgeneric) which will overload the > to accept STRING types as well as NUMBER types. For example, if the arguments of > are of type STRING, the defgeneric will do a string comparison, letter by letter starting from the left until the ASCII codes differ. In contrast, if the arguments of > are of type NUMBER, the system compares the sign and magnitude of the numbers. The user-defined > for STRING types is an explicit method, while a system-defined or user-defined external function such as > for NUMBER type is an implicit method.

The technique of overloading a function name so that the method which implements it is not known until run-time is another example of dynamic binding. Any object reference of name or address may be bound at run-time in CLIPS to functions through dynamic binding also.

Some languages such as Ada have a more restrictive type of overloading in which the function name must be known at compile time rather than at run-time. The run-time dynamic binding is the least restrictive since methods can be created during execution by the (build) statement. However, you should be careful in using (build) since dynamically creating constructs is often hard to debug. Also, the resulting code may be difficult to verify and validate since you'll have to stop execution to examine the code. Dynamic binding is a characteristics of a true object-oriented programming language.

Following is an example of a defgeneric, >, for STRING types and its method.

; Header declaration. Actually unnecessary
CLIPS> (defgeneric >)
CLIPS>
(defmethod > ((?a STRING) (?b STRING))
  (> (str-compare ?a ?b) 0))
; The overload ">" works correctly
; in all three cases.
CLIPS> (> "duck2" "duck1")
TRUE
CLIPS> (> "duck1" "duck1")
FALSE
CLIPS> (> "duck1" "duck2")
FALSE
CLIPS>

The (defgeneric) acts as a header declaration to declare the type of function being overloaded. It's not actually necessary to use a defgeneric in this case because CLIPS implicitly deduces the function name from the defmethod name, which is the first symbol following defmethod. The header is a forward declaration that is necessary if the (defgeneric) methods have not yet been defined, but other code such as defrules, defmessage-handlers, and so forth refers to the (defgeneric) name.

Compared to deffunctions, a method has an optional method index. If you don't supply this index, CLIPS will provide a unique index number among the methods for that generic function, that can be viewed by the list-defmethods command. The method body can be printed using the ppdefmethod command. A method can be removed with an undefmethod function call.

The ranking of methods determines the method precedence of a generic function. It is the method precedence which determines the methods order of listing. Higher precedence methods are listed before lower precedence methods. The highest precedence method will also be tried first by CLIPS.

A shadowed method is one in which one method must be called by another. The process by which CLIPS picks the method with highest precedence is called the generic dispatch. For more information, see the CLIPS Reference Manual.