CPI 101: Meeting 9
Rule-Based Languages
Pat Langley
School of Computing and Informatics
Arizona State University
Tempe, Arizona USA
Traditional Programming Languages
Most languages for creating computer programs taught in
computer science courses emphasize:
 procedural character of routine behavior
 activities that occur in fixed orders
 repetitive steps that use iteration
 relatively inflexible behaviors
This is fine for some forms of routine activity, but they can be
awkward for many others.
Note that conditional statements provide the source of flexibility
in traditional languages.
Rule-Based Languages
An important alternative, rule-based programming languages:
 specify behavior entirely in terms of if-then rules
 emphasize the conditional nature of behavior
 often utilize list structures and pattern matching
 support coding of highly flexible behaviors
Rule-based formalisms have many practical applications, but they
come originally from studies of human thinking.
Within artificial intelligence and cognitive science, they are
sometimes called production systems.
Rules in Everyday Life
Many of our routine activities involve following rules:
 Driving a vehicle
 Solving puzzles
 Playing sports
 Getting degrees
 Talking with others
 Filing taxes
Encoding such activities is generally much easier in rule-based
programming languages.
A Sample Application: TurboTax
Expert Systems
TurboTax is an example of an expert system, a program that:
 incorporates substantial knowledge about some area
 usually encodes expertise as a set of if-then rules
 operates by matching rules against facts or beliefs
 may interact with the user by asking questions
Such systems have seen wide application in business, but they
are seldom taught in computer science courses.
Early expert systems were build by hand, but increasingly they
are created through machine learning.
Another Application: Organizing Weddings
Overview of a Procedural Program
Stored Program
(steps, loops)
Stored Program
Interpreter
Program Variables
(counters, results)
Overview of a Production System
Knowledge Base
(if-then rules)
Recognize-Act
Interpreter
Working Memory
(beliefs and goals)
Representing Rules
A production system stores domain knowledge as rules that have:
 A condition side
 With one or more conditions that must match
 That share pattern-match variables across conditions
 Action sides
 With one or more actions that alter memory
 That share pattern-match variables with conditions
Each rule specifies the actions to take when all of its generalized
conditions hold.
These can match against and modify the environment or memory.
A Sample Rule-Based Program
If you want to subtract Row2 from Row1, and
ColumnX is the rightmost unprocessed column,
Then process ColumnX.
If you want to subtract Row2 from Row1, and
you want to process ColumnY, and
Num1 is in Row1 and ColumnY, and
Num2 is in Row2 and ColumnY, and
Num1 is greater than Num2, and
Row3 is just below Row2,
Then write the difference between Num1 and Num2
in ColumnY and Row3.
A Sample Rule-Based Program (cont.)
If you want to subtract Row2 from Row1, and
you want to process ColumnY, and
Num1 is in Row1 and ColumnY, and
Num2 is in Row2 and ColumnY, and
Num2 is greater than Num1, and
ColumnZ is just left of ColumnY,
Then borrow from ColumnZ to ColumnY.
If you want to borrow from ColumnZ to ColumnY, and
Num3 is in topmost Row and ColumnZ, and
ColumnZ has not been decremented, and
Num3 is greater than zero,
Then take the difference of Num3 and 1 in Row and ColumnZ,
and mark ColumnZ as decremented.
A Sample Rule-Based Program (cont.)
((subtract ?row2 ?row1)
(rightmost-unprocessed ?columnX)
=>
(process ?columnX))
((subtract ?row1 ?row2)
(process ?columnY)
(in ?num1 ?row1 ?columnY)
(in ?num2 ?row2 ?columnY)
(*greater ?num1 ?num2)
(below ?row3 ?row2)
=>
(*add (in (*diff ?num1 ?num2) ?row3 ?columnY)))
A Sample Rule-Based Program (cont.)
((subtract ?row1 ?row2) (process ?columnX)
(in ?num1 ?row1 ?columnY) (in ?num2 ?row2 ?columnY)
(*greater ?num2 ?num1) (left-of ?columnZ ?columnY)
=>
(borrow ?columnZ ?columnY))
((borrow ?columnZ ?columnY)
(in ?num3 ?row ?columnZ)
(topmost ?row) (*not (decremented ?columnZ))
(*greater ?num3 0)
=>
(*add (in (*diff ?num3 1) ?row ?columnZ))
(*add (decremented ?columnZ)))
Representing Beliefs and Goals
Rather than storing changing content in traditional variables, most
production systems:
 retain a set of beliefs and goals
 encoded as symbolic list structures
 in a short-term or working memory
 that changes as the program runs
This representation is based on theories of how people encode the
content of their short-term memories.
They were designed to support symbolic processing rather than
numeric algorithms.
Sample Beliefs and Goals
Our rule-based subtraction program would contain elements like:
(topmost row1)
(below row2 row1)
(below row3 row2)
(left-of column2 column1)
(processed column1)
(borrow column2)
(in 5 row1 column1)
(in 7 row2 column1)
(in 3 row1 column2)
(in 1 row2 column2)
(in 8 row1 column3)
(decremented column2)
These list structures change over time as the program runs.
They are much richer than standard variables, but they also rely
on more powerful ways to access them.
Interpreting Rule-Based Programs
A production system operates in successive recognize-act cycles:
 find all ways that each rule’s condition side matches against
the contents of working memory
 select one or more of the matched rule instances to execute
 instantiate and carry out the actions of the selected matches
These actions change the state of working memory, possibly
letting different rules match on the next cycle.
This process continues until no rules match or the selected rule
executes the halt action.
Interpreting Rule-Based Programs
To find all ways that a rule matches against working memory, a
production system:
 matches each condition against each working memory element
 binds its pattern-match variables to corresponding parts
 checks to see if the different conditions bind consistently
 checks to ensure that no negated conditions are matched
Note that the same rule can match against working memory in
more than one way.
Each set of consistent bindings is an instantiation of the rule.
Interpreting Rule-Based Programs
A production system selects among rule instantiations to execute
one or more on each cycle.
For this, it uses conflict-resolution heuristics that, e.g., prefer:
 instantiations that match against more recent elements
 instantiations that match against more specific sets of elements
 production rules that have more conditions
 production rules that were added earlier
Different languages use alternative selection strategies that may
produce different behavior for the same content.
Modeling Human Cognition
Production systems are often used to model high-level cognition
in people because:
 They support mental activities that make humans unique
 They combine parallel retrieval with sequential decisions
 They balance stimulus-driven and goal-driven behavior
 They offer the right level of analysis for many symbolic tasks
 Their modular representation supports key forms of learning
Some production system languages like Soar, ACT-R, and EPIC
are associated with theories of the human cognitive architecture.
These make claims about the representations and processes that
support mental abilities.
Subroutines and Recursion with Rules
Although production systems focus on conditional behavior, they
also support subroutines and recursion.
If you want to subtract Row2 from Row1, and
you want to process ColumnY, and
Num1 is in Row1 and ColumnY, and
Num2 is in Row2 and ColumnY, and
Num2 is greater than Num1, and
ColumnZ is just left of ColumnY,
Then borrow from ColumnZ to ColumnY.
If you want to borrow from ColumnZ to ColumnY, and
Num3 is in topmost Row and ColumnZ, and
ColumnZ has not been decremented, and
Num3 is zero, and
ColumnX is to just left of ColumnZ,
Then borrow from ColumnX to ColumnZ.
They achieve this by placing goals in working memory that cause
other rules to match or the same rules to match differently.
History of Rule-Based Programming
Production systems have a long history in AI and cognitive science:
 Allen Newell (1967) proposes production systems as models of
human cognition
 Donald Waterman (1970) develops the first running production system
(for learning to play poker)
 Charles Forgy (1976) releases OPS, the first widely used production
system language
 John Anderson (1976) introduces the ACT cognitive architecture
 John McDermott (1980) develops R1, an expert system for computer
configuration
 John Laird (1983) develops the Soar cognitive architecture
Since then, production systems have seen wide use for models
of human cognition and commercial applications.
Soar Technology’s
Intelligent Agent
for Flight Training
Carnegie Learning’s Algebra Tutor
Backward-Chaining Approaches
Production systems carry out forward chaining, but other methods:
 start with a generalized goal or query
 find rules with left-hand sides that unify with that goal
 chain off each of the subgoals in their right-hand sides
 return bindings upward when reaching terminal nodes
This technique generates not only answers to queries, but also
proofs for why they hold.
Such backward-chaining methods emphasize inference rather
than action; they are similar to relational databases.
PROLOG is a well-known language that supports backward
chaining over first-order logical rules.
Summary
Rule-based programs provide an important alternative to more
traditional procedural languages that:
 specify behavior entirely in terms of if-then rules
 match or unify these rules against list structures in memory
 carry out actions or draw inferences based on these matches
 provide greater modularity than procedural languages
Rule-based programs are commonly used to develop expert
systems, which underlie many business applications.
Production systems are often used to model high-level cognition
and explain important aspects of human behavior.