"

"

New Programming Languages for Artificial IntelligenceResearch

DANIEL G. BOBROW Xerox Palo AltoResearch Center, Pah Alio, California 94304

BERTRAM RAPHAEL StanfordResearch Institute, Menlo Park, California 94025

New directions in Artificial Intelligence research have led tothe need for certainnovel features tobe embedded in programming languages. This paper givesan overviewof the nature of thesefeatures, and their implementation in fourprincipal families of AI language*: SAIL-PLANNER/COXXIVER; QLISP/INTERLISP; and POPLER,POP-2. Th«-programmingfeatures described include :new data types and accessing meeh.vni.iins for stored expressions;moreflexible control structures, includingmultiple processes and backtracking; patternmatching to allow comparison of data item with atemplate, and extractionof labeledsubexpressions; and deductive mechanisms which allow theprogramming system to carry outcertain activities includingmodifying the data base and deciding which subroutines to run nextusing only constraints and guidelines set up by theprogrammer.

Key words and phrases: programming languages, artificial intelligence, datatypes, controlstructures, pattern matching, deductive mechanisms. CR Categories: 3.C0,4.22, 4.33,4.34

X INTRODUCTION

Most programming languages areuniversal in the sense that any algorithmthat can be expressed by a program in onelanguage can also be expressed in any of theother languages. However, the set orunique facilities provided by a languagemakes some types of programs easier towrite in that language than in any other.Indeed, the mainreason for introducing newfeatures into a programming language Is toautomateprocedures that the user needs andwould otherwise have to code explicitly;such features reduce the housekeepingdetails that distract the user from thealgorithms in which he is really interested.Therefore, underlying the design of anyprogramming language is a set orassumptions about the types of programsthat users of that language will be writing.

Historically the needs of the artificialintelligence (AI) research community havestimulated new developments inprogramming systems. The first high-levellist-processing primitives were developedby Gelernter for a geometry theorem prover(Gelernter 1959); the first general string-

manipulation system was developed byYngve for computational linguisticsresearch; the first wide uses of conditionalexpressions and recursion were at leastpartly due toJohnMcCarthy'sAI Interests.

For more than a decade, the list processingand symbol-manipulation languages—suchas COMIT, IPL,LISP, SUP (Bobrow &Raphael1964)--have been the media for almost allAI achievements. Although theeffectiveness or research with theselanguages has improved dramatically dueprimarily to greatly expanded memory sizesand new Interactive debugging facilities,the languages themselves have remainedremarkably stable. In recent years,however, new directions for emphasis in AIresearch —such as studies of representationof knowledge, robotics, and automaticprogramming—have led to a widely feltneed for certain rather novel features to beembedded into programming languages; andsome languages containing several of thesefeatures have recently been implemented.The purpose of this paper is to give anoverview of the nature of these newprogramming features and the present stateof their availability in the new languages.

Computing Surveys,Vol. 6, Xo. 3, September 1974

The languages to ba discussed in thispaper are generally in an early stage ofdevelopment: they are inadequatelydocumented; neither the designs nor theimplementations are fully debugged; theyhave been used at most for only a fewsignificant application programs; and theyare so dependent upon local operatingsystems and environments that they areextremely difficult to export. However, thecommon threads of new ideas runningthrough these languages appear so basic anduseful that some of the languages havealready received widespread publicity, andonce the ideas stabilize, the successors tothese systems are likely to provide the basictools for AI research for years to come.

In this paper we shall not attempt toidentify and describe specific, completelydefined languages, because suchdescriptions would rapidly become obsoletein view of today's level of activity in thesystem design area. Instead, we shall devotethe next section (Section III) of the paper tcdiscussing the newfeatures present in manyof the emerging systems. Section IV willthen compare how these features are beinghandled in each of four evolving families oflanguages being developed at differentmajor AI research centers:

(I)SAIL. a language developed at theStanford AI Project (Swinehart &Sproull 1971);

(2)PLANNER and CONNIVER, systemsbeing developed at the MIT AIlaboratory (Sussman & McDermott1970;Baumgart 1972; McDermott

Be Sussman 1972);

(3) the QLISP language being developed atSRI (Reboh & Sacerdoti 1973) asan extension of INTERLISP(formerly called BBN-LISP) whichis a Joint continuing product ofXerox PARC and BBN (Teitelman1974)

(4) the POPLER extension of POP-2 from,the University of Edinburgh(Davies 1973).

These four sets of languages each havelong, independent histories.

SAIL is a marriage of LEAP (Feldman1969), an associative retrieval

formalism, and a version of ALGOL 60.It has been in use at Stanford since1969. Recent improvements,stimulated by the needs of AIresearchers, have been primarilyfocused on adding more powerf ul andflexible control mechanisms.

The PLANNER concept was developedby Hewitt at MIT starting in 1967(Hewitt 1971, 1972), and Sussman andWinograd built a first implementation,MICRO-PLANNER, which contained asubset of PLANNER features.' Theseprojects established the basis of thecurrently popular conceptof proceduralrepresentation of knowledge.CONNIVER is a recent attempt bySussman at MIT to remedy someobserved shortcomings in the practicaluse of PLANNER, while preserving itsgood ideas.

QLISP was a successor to QA4, whichwas developed primarily by Rulifson(Rulifson et al 1968, 1973) at SRI.These languages evolved from years ofquestion-answering and theorem-proving research. Although stronglyinfluenced by PLANNER, QA4 wasintended to be a more uniform andcomplete formalism. QLISP is a currentattempt to make QA4 features moreaccessible by merging them into anestablished, widely available LISPsystem INTERLIS?. INTERLISP isproviding a general control structureframework at the systems level alongwith many user Interaction facilities.

POPLER is largely based on the ideas inPLANNER, hut is implemented andembedded in POP-2. POP-2 provides acompiler-oriented stack machine withan extensible data type facility.Although POPLERI.S has been availableonly since spring of 1973, POP-2 hasbeen in use for AI research at theUniversity of Edinburgh for a numberof years.

m

(

"

154 Daniel G. Bobrow and Bertram Raphael

CirmputiriK S'irv>'\«. \\>\. C, Nu, 3, September 1974

I. Introduction11. Languages Covered111. New Common Features

123

[V. Language Feature ComparisonsV. Conclusions

717

Bibliography 20

II LANGUAGES COVERED

(155

"

The following paragraphs discuss some ofthe special features of the new languagesand why they are desirable. These specialfeatures deal with:

Data types and memory management

Control structures, including pseudo-parallelism, conditional interrupts("demons"), alternative contextsand backtracking

Pattern matching, used for both dataretrieval and program control

Automatic deductive mechanismsIn order to present the principal featuresof these languages in a reasonable amount ofspace. the following discussion isnecessarily oversimplified. Following asimple example illustrating how some ofthese new features facilitate AIProgramming we look at common featuresof the new languages. We take some libertywith syntax in the sample problem,.and inthe comparisons in Section IV, to make shortexamples readable out of context. Manyfeatures of each language will not bediscussed. The reader should rerer to theappropriate rererence manuals noted aboveSL J*?* accurate and completepresentations or details.

A. A Sample Problem

The following problem has been adaptedfrom the functional form of naturalJ?££nCG«

th3t h3S been P«*««nm«!tcZ L ln. IN7ERLISP Carbonell's?"2^«fyStem <Carb°neH & Collins 1973).SCHOLAR is a mixed-initiative dialog systemwhich acts as a tutor and question answererwith respect to a semantic network database. One such data base concerns thegeography of South America, and SCHOLARuses a strategy called functional inferencetoprovide plausible answers to certain typesof questions for which it does not havedirect data. As illustrated in the simulatedEnglish dialog below, it uses the functionaldeterminants of a property (e.g., cropsgrown are determined by soil and climate)to compute answers by analogy. TheSr^fm rollowlnS. written In a MICRO-PLANNER/CONNIVER style dialect, followsthe English protocol in finding the sameanswer.

Question* What crops grow in Uruguay?Answer: Well, I can't think of anything Iknow which directly answers thatquestion, so perhaps I can find a similarcountry and see what it grows. Cropsdepend on climate and soil conditions,which for Uruguay are "temperate" andfertile . Ecuador has a temperate climate,but its soil is barren. Let's try anothercountry. Paraguay has the same climate andsoil and it grows wheat. So Uruguayprobably grows wheat.

Program question:(GOAL (GROWS URUGUAY 7X))

Program data bases(CLIMATE URUGUAY TEMPERATE)(SOIL URUGUAY FERTILE)(CLIMATE ECUADOR TEMPERATE)(SOIL ECUADOR BARREN)(CLIMATEPARAGUAY TEMPERATE)(SOIL PARAGUAY FERTILE)(GROWS PARAGUAY WHEAT)(GROWSECUADOR CACTUS)

Functional inference rule:

[IFNEEDED(GROWS 7COUNTRY 7CROP)(ANSWER (PROBABLY

(GROWS 7COUNTRV 7CROP)))

(AND (CLIMATE 7COUNTRY?CL)(SOIL 7COUNTRY ?SL)(CLIMATE ?Y 7CL)(SOIL ?Y ?SL)(GROWS ?Y 7CROP))]

Trace: The data base is first searched for adata item which directly matches theTw" SPeC'flod in the GOAL statement.The ? marks X as a variable whose valueor values are to be found. Failing tore rieve any stored answer, the systeminterpreter tries to retrieve a procedurewhose target pattern matches the goalstatement. The IFNEEDED procedure shownhas such a pattern, and will return theanswer pattern with all free variablesinstantiated if the search specified by theconjunction is successful. When the targetpattern is matched, the variable 7COUNTRY

« JH!? 6^"*the unction*used Jo find appropriate values ror the(associative retrieval) from the data basethe variable ?CL Is bound to TEMPERATE*ECUA^V0

tEhRTILE; th6n ?Y ,S bo«^ £feSS?2? hC pro*ram P-w«els the

n, SS"nswer Protoc°l. The value of theCLIMATE of ECUADOR is checked, and then

Computing Surveys, V.,1. fi,.X„. 3, *>pteml„. r 1!»74

the property of Ecuador's SOIL. SinceBARREN does not match the FERTILE ofURUGUAY, the system interpreterbacktracks to its last decision point. Itchooses another country, PARAGUAY, in thedata base to test for satisfaction of thecriteria for functional similarity toURUGUAY with respect to crops.

This example illustrates how patterns areused for retrieval of data items, for pattern-?directed invocation of a procedureapplicable to the achievement of a specifiedgoal, and backtracking, a control regimeautomatically invoked by the systemwithout specification needed by the user.The features illustrated are selectedexamples from a wider class of capabilitiesfound in in this new generation of AIlanguages. None of these features areautomatic in the earlier AI programminglanguages; thus the user had to attend to allthe details, distracting him from the contentof his problem. It is this upgrading oflanguage level that we focus on in thediscussion below.

B, Data Types

The earliest programming languagespermitted the user to manipulate onlynumbers, either as scalars or arrays. Themajor contribution of the symbol-manipulation languages was theintroduction of symbolic data types, such aslists, trees, and strings. A few languages,including SMOBOL4 (Griswold et al 1968),permit the user to define additional types ofdata structures; but such data extensionfacilities are not widely used, probablybecause the user then has the burden ofproviding all the basic operators needed towork with his new data type.

Lists, trees, and strings were adequatebuilding blocks as long as AI researcherswere groping for representations andalgorithms to handle Idealized "toy"problems. Recently, as the emphasis hasshifted to larger, more complex, morerealistic problem domains, a greater varietyand richness in data types have becomedesirable. In particular, in addition to lists,trees, and strings, one would like to be ableto use content-retrievableordered triples (orn-tuples), unordered sets, and formalstatements of a logical formalism or aprogramming language, as basic data types.These are operationally different types, butstill basically problem independent, e.g., anunordered set, not a personnel record. For

each data type, the programming languageshould provide a set of operations orfunctions needed to create items of thattype, toperform basic manipulations on thattype (e.g.. LISP'S car, cdr, and cons forbinary trees, union and intersection forsets, etc.), and when appropriate totransform one type into another. All of thenew languages provide important new datatypes and a framework for their use.

The symbol-manipulation languages, likemost otherprogramming languages, left theprogrammer with full responsibility forcreating, indexing, and accessing any datafiles he wished to use. Recently, AIresearchers have recognized the need forlarge, relatively permanent informationfiles that must be maintained and accessedin an efficient manner. In some cases thesefiles must be divided into sections that areeach available only to certain programsunder certain conditions. The newlanguages provide built-in, automaticmechanisms for handling such datafiles in aconvenient way, including storage ofstructures, and retrieval of storedinformation on the basis of a pattern (seesection HID).

C. Control Structures

In the earlier AI languages the flow ofcontrol among procedures or functions, theprimitive units of program that we shallhere call access modules, was strictlyhierarchical. An access module is any unitin which is introduced new bindings, thatis, associations between variable names andvalues. In hierarchical control, everymodule was expected to complete its work(perhaps calling other modules) and thenreturn control toits parent, the module thatactivated it. Recursive control waspermitted, i.e., a module could call itself orone of Its ancestors in the control hierarchyas a subroutine! however, each suchrecursive call to a module could be thoughtof as creating a separate instance oractivation of the module to be used at a newlevel so that the strict hierarchy wasmaintained. Moreover, once an activationhad been exited, it disappeared and could notbe "continued" again. The bindings in thatmodule were lost. Reinitiating a modulecaused a new activation of the module to becreated andrun from its beginning.

A generalization insome LISP systems wasthe so-called "funarg" mechanism, which

m

(.

"Computing Surveys, Vol. fi, No. 3, September 1974

156 Daniel G. Bobroiv and Bertram Raphael

Xciv Programming Languagesfor Artificial Intelligence Research 157(allowed a set of variables and their currentvalues (bindings) to be passed from one partof the control tree to another independent ofthe continued existence of the definingcontext. This feature allowed use of freevariables in the definition of a functionalargument which would not conflict withuse of the same variable in the program thatcalled the functional argument,returning toa higher level a function with specifiedbinding environment for free variables, andpreservation of variable values betweencalls. However, the basic relation betweenaccess modules was still strictlyhierarchical. Special purpose coroutinesexisted in the IPL-V "generator" feature,which allowed reentry to certain predefinedroutines, usually for scanning data basesincrementally.

Much more flexible control structure is amajor contribution of the newer AIlanguages. The basic control innovationthat is now being made available is theability to save a module and its context in astate of suspended animation. An activeaccess module can relinquish control notonly by returning control to its parent andvanishing, as in a hierarchy, but also bygiving control to another module that is insuch a suspended state. The suspendedmodule is poised to continue executionfromright where it left off. The "resumer" cansave his own state, but no other module isobligated to "return" control to such asuspended module in order to complete acomputation. Thus in addition to moving upand down hierarchical trees by initiatingand terminating execution of accessmodules, flow of control may now alsowander among the access modules bysuspending and resuming their executionsin any order, unconstrained by the treestructure of their inherent controlrelationships. Each activation will have aunique caller, i.e., the module that initiated(and thereby created) it, but it may also bereached from (and transfer control to) anynumber of other modules.

In order to make this flexible controlflow possible, the implementations of thenew languages must provide for appropriatebookkeeping. Bobrow and Wegbreit(1973b) define a general model for controlthat has been used as the basis for suchimplementations including those in three ofthe languages described below (CONNIVER,INTERLISP and POPLER). This model definesthe set of information or frame that must beassociated with every activation of an accessmodule, to make possible its suspension and

reactivation in a meaningful way. Thisinformation includest

( 1) A binding link that specifies where tofind values (bindings) of variables localto thisactivation (such asLISP prog andlambda variables).

(2) An access link that specifies theenvironment in which to find valuesfor free variables (not specified in thelocal environment,and normally foundin LISP, for example, by tracing up thehierarchical chain of control).

(3) A control link that specifies whichmodule activation is to continueprocessing if the current moduleterminates at a "normal" exit (such as aconventional return statement).

(4) The process state in the module,which specifies where and how tocontinue a previously suspendedoperation. This includes currenttemporaries, and the current "programcounter".

A point to note about a frame of an accessmodule is that it has in the frame itself allthe information necessary to continuerunning the activation; e.g.. thecontinuation point and values of temporaryvariables of a module at the time it callsanother access module are stored in thecaller. Because independent returns to aframe may require distinct continuationpoints and temporary storage, a separatecopy of this part of the frame must be madefor each independent successor, althoughthe bindings need not becopied.

The control structure induced by thismodel is a tree of modules, with controlpassing among any of the suspendedmodules in the structure. If only oneprocess is active at a time, we call it acoroutine regime. If processing can bethought of as going on simultaneously inseveral modules, we call it amultiprocessing regime. Multiprocessing isusually done by scheduling through time-quantum interrupts at the system level, ortime allocation in the language interpreter.It can also be effectively achieved in acoroutine regime by cooperation, e.g., byhaving each active process frequentlyresume an executive module to requestfurther resource allocation.

Backtracking is a special coroutineregime in which instances of modules are

m

# Computing Surveys, Vol. fi, No. 3, September 1074

"Daniel G. Bobrow and Bertram Raphael158

(

#

saved at decision points, and restored in alast-in-first-out sequence when subsequentmodules "fail" (a special form oftermination). In addition to restoring thecontrol environment (automatic onresuming processes), some alternativephilosophies have developed on restorationof the data state—sometimes called the datacontext—which existed at the time thedecision point was saved (both for variablebindings and general data bases). Somesystems normally "undo" all data changes(e.g., MICRO-PLANNER) some only bindings(e.g., LISP7O (Tessler et al 1973)), and someprovide a programmable facility for undoingany specified changes (Teitelman 1969).Backtracking as a search mechanism followsa strictly depth-first search on a decisiontree, and this formerly popular controlmechanism has been criticized (Sussman andMcDermott 1972) for its inefficiency inmany situations.

Another addition to the AJ jargon in thecontrol domain is the demon, which is amodule that is automatically activatedwhen certain conditions become true.Demons are usually implemented by havingdata-accessing functions check for"sensitive data", evaluating the currentmonitoring condition involving thesensitive data "touched", and having thosefunctions transfer control to the demonmodule when appropriate.

D. Pattern Matching

Pattern matching was first usedextensively in the string manipulationlanguages (COMIT, SNOBOL), in order topermit substrings to be identified by theircontents rather than by their addresses.Thiskind of data specification is extremelyuseful in current AI applications thatfrequently require large symbolic datastores, so some form ofpattern-directed dataretrieval has been included in all the newlanguages.

Pattern directed data retrieval will find ina data base one. some or all items whichmatch some user specifications. Theretrieval takes place in two steps. The firstis retrieval from a data base of an item (oritems) which seem likely to match on thebasis of elements contained. This retrievalis usually done through an indexed lookupon key elements. The second half, checkingthe user specifications, is most orten doneby matching the data items against a user

specified template, -which may contain anumber of variables. In such a template,there is a reversal from the usual LISPconventionwhere constantsare marked by aquote symbol, and unmarked identifiers areassumed to be variables. In a template anunmarked identifier is matched directly (asa constant), and a variable is matchedaccording to a prefix which Indicates itstype. When a variable matches an item, theitem, is made the value of the variable.

There are two variable modes and fivevariable types found in the languages beingdescribed, though not all are found in eachone. The two modes axe the unit variable,which can match any single (unitary)element of a structure; and the segmentvariable, which can match an arbitrarynumber of elements at the same level in thestructure. These modes are an independentfeature of the variable for each of thefollowing variable types (where "itera" isused for "itemor segment"):

1) Open: An open variable will matchany item;

2) Closed: A closed variable will matchonly an item equal to thepreviously assigned value of thevariable;

3)Semiopen: A semiopen variable willmatch any item if it has not beenpreviously given a value; it willmatch the previously assignedvalue when it has one. Thus, itacts as an open variable the firsttime it is encountered, and aclosed variable after that;

4)Restricted: A restricted variable willmatch items that satisfy a set ofrestrictions which may bespecified for that variable, e.g.,only match elements of- aparticular domain;

5) Macro: A macro variable has its valuesubstituted in the pattern before amatch takes place, thus allowingindirect reference to variables,forms, etc.

The variables are instances of whatHewitt (1972) called pattern actors whichare functions which run during thematching process. (Hewitt et al (1973) usedthe term "actor" for a different but relatedconcept described briefly in Section V).Pattern actors are predicates used inside a

-Computing Surveys, Vol. (*>, No. 3, September 1074

NewProgramming Languagesfor Artificial IntelligenceResearch( 159

#

"

template for matching, and some of thelanguages allow the user to define newmatching functions to augment the systemrepertoire. Templates provide a veryflexible and easily understood way tospecify the form of data items required,without the user having to be aware of howitems are stored. A template may matchmore than one Item, and it may match anItem in more than one way, so some pattern-matching facilities allow the user to specifywhether he wishes all possible matches tobe found at once, or one match at a time (onrequest) after each preceding one isprocessed.

In addition to searching through a database, pattern matching may be used as partof the control mechanism to select the nextsubroutine. Here each subroutine contains atemplate as part of its definition, and thesubroutine can be executed only if itstemplate matches its actual argument. Acommon use for this mechanism is in goal-directed problem solving systems. Supposeeach subroutine is capable of producing asits output a certain, unique form of datastructure; then a template describing thatTorm is included in the definition of thesubroutine. Now when the top-levelprogram wishes to achieve a "goal"— e.g„produce a certain data structure—it needmerely call for the execution of anysubroutine that matches the goal, withoutknowing which particular subroutine willstep forth; the system provides a decisionmechanism for choosing an order if severalare applicable, and sequencing throughthem on failure. Such use of pattern-directed function Invocation (originated inPLANNER (Hewitt 1971)) permits"knowledge" to be distributed throughoutthe programs of a complex system,permitting more flexible modification andgrowth of AI programs than would beallowed by the more conventional top-downhierarchical control.

E. Deductive Mechanisms

The extent to which a programmer mayspecify what he wants accomplishedwithout detailing how it is to be done is oneway of defining the "level" or "power"of aprogramming language. For example, thelowest level computer languages, assemblycodes, require an explicit statement for eachwired-in instruction to be executed.Algebraic languages, such as FORTRAN,permit the user to describe a desired result

by a combination of mathematical relations,e.g., x=a+b-c, and leave to the compilerdecisions about the order in whichelementary commands are performed. LISPprograms may be recursive, in which casethe system has added responsibility forstack manipulation—and possiblytranslating the recursion intoan iteration.

The new languages go a step further.They permit the programming system tocarry out certain activities, includingmodifying the data base and deciding whichsubroutines to run next, using onlyconstraints and guidelines the programmersets up for each programmed activity. Forexample, the programmer can request aresult, and the procedures which "match"the request will be tried by the systemusing a. problem solving mechanismworking within the pre-establishedguidelines. The process of constructing aproblem-solving program then becomes amatter of developing and modifyingguidelines. and specifying matchingcriteria, rather than developing proceduralalgorithms. We call the semi-automaticsearch and data-construction features ofthese languages deductive because they bearsome resemblance to so-called "theorem-proving programs" that attempt to deducedesired logical expressions (theorems) frompreviously specified expressions (axioms).The mechanisms built into these languagesallow expression of many strategies forproving different types of theorems, and/orsolving complex problems.

IVLANGUAGE FEATURE COMPARISONS

A. Data Types and StorageMechanisms

In this section we describe the novel datatypes of the various languages and howthey are formed, stored, accessed, andmanipulated. Of course, these languagesalso have the usual arithmetic data typesand individual variable and array storage,which are generally unexceptional andneednofurther discussion here.

I. SAIL. SAIL is an ALGOL-like languagewhich contains a symbolic data systembased upon an associative storagemechanism (originally called LEAP(Feldman fc Rovner 1969)). The basicelement of this system is the item, a uniquedata element which may be named by an

Computing Surveys, Vol. 6, No. 3, September 1974

160 Daniel G. Bobraw and BertramRaphael

"

('_■;

#

identifier and referenced by an item-variable. Two kinds of structures may beformed from items:

Sets of items

* Associations, which are orderedtriples of items.

An association of three items is usuallydenoted

where iteml, item2, and item3are called(appropriately enough) the first, second, andthird elements of the association,respectively. They are also occasionallycalled the attribute, object, and value of theassociation in suggestion of the semanticsusually given associations, e.g.,

COLOR® APPLE sRED

is a typical association.

An association may itself be designated tobe an item included as an element of higher-order associations. However, the use ofsuch nested associations appears to besomewhat awkward.

Appropriate functions exist for creatingand deleting associations, and for insertingand removing items from sets. In addition,the FOREACH statement convenientlyspecifies iteration through sets, e.g.,

FOREACH x SUCH THAT X IN setDO statement

causes statement to be executed repeatedlyfor X bound to each element of set in turn.

The most important feature ofassociations is that they are automaticallystored in a permanent data structure thatmay be accessed in an associative manner.In particular, the set referenced in aFOREACH statement can be implicitlydefined by referencing the association store;e.g.,

FOREACH x SUCH THATCOLOR © x * REDDO statement

will cause all known red things to beprocessed by statement, even though nosuch explicit set had been created. FOREACHstatements also allow looping throughcorresponding pairs, triples... In addition,the special symbol ANY can be used as a

"don't care" comparator; thus thespecification COLOR &x~ ANYdefines the setof all objects x that have any coior attributein the association memory.

The sets and associations in SAIL provide aconvenient, efficient mechanism foraccessing certain symbolic data structures.However, sets and triples are not necessarilyas convenient as list structures for manyapplications. For this reason a new datatype, list, has recently been added to SAIL. Amajor problem- ..with these lists is that theonly legal elements of these lists are items,thus making it difficult to representmultilevel linked structures such as treesand graphs la a uniform way in a liststructure.

2. PLANNEE/CONmVEE. Full PLANNER(as definedby (Hewitt 1972)) is an evolvingtheoretical framework of programminglanguages, and therefore is not anappropriate candidate for this review ofexisting systems, though a number of itsIdeas will be discussed. The PLANNERsystem described here is the MICRO-PLANNER implementation defined in(Sussman & Winograd 1970). MICRO-PLANNERand CONNIVER are implemented inLISP and allow access to LISP constructs.Thus all LISP data structures are availablewhen needed—although care must be takento distinguish between LISP and PLANNERvalues of similar variables.

PLANNER makes available to theprogrammer two semantically differenttypes of data items: assertions andtheorems. An assertion is an ordered n-tuple represented by a LISP list of non-numeric objects called items. The range ofpossible formats for assertions is wide,except that by convention an assertionusually represents a true fact. For example,the following arepossible assertions:

(SMELLY GARLIC)

(SMALL-PRIMES ( 1 23 5 7 11) )

(COLORAPPLE RED)

(THIS IS AN ASSERTION)

Assertions may be created, erased, andassociatlvely accessed in a manner similar toSAIL associations.

Theorems in PLANNER are the procedures

iteml & item2= item3

Computing Surveys, Vol. f>, No. 3, September 1074

New Programming languagesfor Artificial IntelligenceResearchC 161

"

"

or subroutines of the language. Eachtheorem contains as part of its definitioninformation about when it should beinvoked and what kind of effect it isexpected to have upon the data base ofassertions. Thus theorems are procedural,describing actions to be carried out, asopposed to the declarative assertions.However, theorems as well as assertionsmay be dynamically created or modified byrunning programs (e.g., by the execution ofother theorems).

An explicit data-base context mechanismis an Important independent CONNIVER andQA4 innovation. Instead of a single globalbase to which assertions (items) may beadded or removed, CONNIVER has a tree ofsuch data bases. Any modification of thedata base occurs only in that data associatedwith the current node of the context tree,and data contexts may easily be changedunder program control. For example, a gamesituation can conveniently be representedby a context tree of board position wherethe highest context is the initial positionand each lower context is derived from itsparent by making justthe changes requiredfor the current move. This structurepermits consideration of alternativesituations merely by switching contexts,rather than making extensive changes tothe data base. (Of course, at some pointthese changes must actually be performed,or else the data base must be multiplygenerated and stored; but CONNIVERtransfers the responsibility for thisbookkeeping from the programmer to theImplementation.)

3. QLISP/INTERLISP. QLISP hasattempted to provide a full range of datatypes, in order to give the programmerconsiderable freedom in choosing arepresentation for his problem domain. Themajor data types are: tuple, class, bag, andvector. Built-in functions provide forforming, combining and testing data of thedifferent types. All QLISP data structuresare stored in a permanent data base calledthe discrimination net. Insertion into thenet converts any element into a canonicalform so thatevery possible expression has aunique representation and location in thenet. Because expressions in the net haveunique locations, they can be givenpermanent property lists just like those ofLISP atoms. These properties are used in thedeductive process described later.

Tuples (short for "n-tuple") and vectorsare simply LISP lists with any number ofelements, but are made unique by thediscrimination net search. A tuple andvector differonly in their evaluation rules.

A class is -viewed as unordered, andrepeated elements are ignored; e.g., thefollowing, are equivalent;

(CLASS ONION (TUPLE MILKEGGS)POTATO ONION)

(CLASS (TUPLE MILKEGGS) ONION POTATO(TUPLE MILK EGGS))

Internally, classes are put intolexicographic order with duplicationsremoved. A bag is an unordered tuple, orequivalently, a set that may have repeatedelements; e.g.. (BAG A B B) is equivalent to(BAG BAB) but differentfrom (BAG A B). Itis particularly useful to know that theargument of certain operators are bags. Forexample, if we say that the argument ofPLUS is a bag, then we need not assert thatPLUS is associative and symmetric, becausethe system already knows this as propertiesof bags.

4. POPLER. The data type mechanism ofPOP-2 allows creation of new datastructures with fields of arbitrary size andinterpretation. It provides astraightforward way of defining theconstructor, accessor, and updater functionsof any new type, and automatic storagemanagement of the data elements. Forexample, if we want to define a record tostore information about a person's name/ageand sex, we would like to use a pointer toreference the arbitrary length name, 7 bitsto allow an age up to 127, and 1 bit toindicate sex. Executing the following!

recordfns("person", £0 7 1])

creates a record type "person" with thesethree fields (0 is used to indicate a fullpointer width) and the appropriate creation,accessing and updating functions for therecord type.

The POPLER extension of POP-2 alsoprovides an "associative" memory for itemsof certain kinds modelled on CONNIVER.The data base Is interrogated by using aretrieval pattern, and items which match(instantiate) that pattern are retrieved. Listconstants and procedures (corresponding to

Computing Surveys, Vol. 0, No. 3, September 1974

Daniel G. Bobrow and Bertram Raphael162

"

"

PLANNER assertions and theorems) arestored in separate data bases. Within eachdata base, items are stored in a particularcontext. The separation of data basesfacilitates access to the more rapidlychanging contexts of data without slowingretrieval of pattern-invoked procedures. Acontext Is a tree-like data structure used tocontrol the scope within which any item ispresent. As in CONNIVER, this permitsconsideration of alternative situationsmerely by switching contexts rather thanchanging a global data base. In order tofacilitate access to items, POPLER providesan index to all items asserted in any state.This ensures one unique copy is used by allthe states. The use of a global indexintroduces one problem in garbagecollection. Some states may becomeInaccessible, and therefore so should someitems; but the index still holds a pointer tothe items. POPLER allows the user to getaround this problem somewhat byspecifically "unindexing" items.

B. Control Structures

The usual hierarchical recursivesubroutine call and return are provided inall the systems. We describe here featuresfor multiple control environments, andpseudo-parallel operation.

1. SAIL. As a compiler-based system, SAIL(Feldman 1972) insists that points in theprogram at which branches in the controlstructure can take place be known atcompile time. Thus the flow of control forthe complete computation is constrained tostay within a branching structure definedin advance; e.g., no process can decideduring execution to create a process thatbranches from above itself in thehierarchical control chain. Only the currentcontrol context can be split.

A new process iscreated by the command

SPROUT {hem, procedure)

where item names the new process forfuture reference, and procedure specifiesthe program that the new process is toexecute. A SPROUTed process is assumed tobegin running immediately and runs inparallel with the process that executed theSPROUT instruction. Since true parallelismis not possible on a single -processorcomputer, the SAIL runtime system includesa scheduler that supervises the

multiprocessing regime by deciding whichprocess is to be executed at a given instant.Processes can contain instructions tosuspend or terminate themselves or otherprocesses, and can specify priorities andtime quanta for running. A coroutineregime is facilitated by aRESUME constructwhich suspends the current process andreactivates a named suspended process.Multiprocess time coordination is done byJOlN(sei) -which suspends the processcalling JOIN until all processes in the sethave terminated. Backtracking within aprocess is possible, but the programmermust explicitly identify places to whichbacktracking is possible, and then specifywhich variables are to have their valuesrestored. No mechanism is available for oneprocess to evaluate a particular expressionin thebinding contextof another process.

Additional communication amongprocesses is facilitated by a kind of mail or"notice" service based upon a messagequeuing system. Any process may placemessages for other processes into variousqueues; processes may themselves be placedon other queues, while waiting for anappropriate message. One of the jobs of themultiprocessing scheduler is to "deliver themail" whenever possible. Demons can beImplemented by means of this message-queuing mechanism, although no specialones are standardly available.

2. PLANNER/CONNIVER. Both MICRO-PLANNER and CONNIVER are implemented asinterpretive languages written in a LISPsystem which permits only a standardrecursive call control structure (plus thepossibility of machine-languagesubroutines); therefore, the flexible controlfeatures of the new languages must bedesigned into their interpreters and are notavailable to LISP functions. These featuresessentially provide modules with thebinding, access, control, and state-savingInformation required by the general controlmodel described earlier (Sec. IIIC).

In MICRO-PLANNER, the general controlcapabilities are not directly available to theuser; the system provides the user withestablishment of backtrack points (bypattern-matching or GOAL statements), andthe automatic restoration of appropriatecontexts whenever backtracking takesplace. Furthermore, backtracking can beinvoked either explicitly (by a FAIL

ComputingSurvey*, Vol. (i, No. ,i, September 1074

New Programming Languagesfor Artificial IntelligenceResearch/ 163

"

"

statement), or spontaneously when a processruns out of things to do.

In CONNIVER, every time a non-atomicexpression is evaluated by the interpreter, anew frame is created. In addition, all thecomponents of every frame—boundvariables, access link, control link, and soon—are available to the programmer. Thus,by explicitly referencing and modifyingframes a CONNIVER programmer may createany kind ofcontrol regime he wishes.

The FRAME command produces a pointerto the current frame, so that it may bemodified or executed again later. The TAGcommand is similar to FRAME, but alsospecifies a starting location within theframe rather than the entire frame. Forexample, after execution of the CONNIVERversion of the program

(PROG (X)(SETQ X 50)(SETQ G2 (TAG A))(SETQGI (FRAME))(PRINT TOO)

A (PRINT 'FIE) )

the global variables Gl and G2 would bothpoint to a frame Within this PROG. Thesubsequent command (CONTINUE GI) wouldstart right after the (SETQGl (FRAME)) andprint both FOO and FIE; (CONTINUE G2)restarts at A and would print FIE only.

Frames may also be used to specify abinding context. The CEVAL commandrequests evaluation relative to a specifiedcontext. Thus after the above PROG hadbeen run, thefollowing code:

(SETQX 17)(PRINT(CEVAL 'XGI))

■would print 50.

In addition to the basic frame-manipulation commands, CONNIVER alsooffers the programmer some higher-levelcontrol constructs. For example, theAU-REVOIR command for exiting from afunction first constructs a continuationpoint using FRAME so that the exitedfunction may be resumed at a future time.This facilitates the construction of

coroutines. Additional special functions andmessage-passing conventions are providedfor facilitating use of generators, a specialkind of coroutine process which cangenerate requested data items one or a fewat a time, and when more are requested,resume processing in their originalcontexts. The IF-ADDED and IF-REMOVEDprocesses are demons which are activatedwhen items are added to or removed fromthe data base. Although the backtrackingregime of PLANNER would be easy toprogram in CONNIVER, it would conflictwith a major motivation of CONNIVER(Sussman & McDermott 1972) to allow theflexibility of multiple processes withpossibly independent data base contexts.Decision points and failure mechanisms arenot provided in the basic systems because itwas felt that this encouraged poorprogramming practices.

3. INTERLISP/QLISP. QLISP is primarilya subroutine package, plus some syntacticextensions embedded In INTERLISP(Teitelman 1974). Unlike CONNIVER withMIT LISP and POPLER with POP-2, QLISPand INTERLISP procedures operate in thesame control world. Since QLISP has noseparate interpreter, its control structure iscompletely dependent upon that ofINTERLISP. A general frame-orientedcontrol structure has been implemented inINTERLISP using a "spaghetti stack"technique (Bobrow & Wegbreit 1973a)which has the property that for ordinaryrecursive function calls it costs very littlemore than the usual stack storage allocationmechanism. The INTERLISP frame containsthe usual binding, access, and control linksand a continuation point (current state), asdescribed earlier, plus some other fields foradditional features. Functions exist thatenable the programmer to locate existingframes by name or by following along accessor control chains, creating a new processusing any existing frame as above, andconstructing arbitrary control structuretrees of new frames. Multiprocessing isdone by explicit passing of control amongprocesses, or to a user-programmedscheduler.

An extremely general relative evaluationfunction permits independent specificationof both access and control environmentsbefore evaluating a specified expression.The effects of both the CONTINUE and theCEVAL commands or CONNIVER and therelative stack evaluation ofBBN-LISP can be

Computing Surveys, Vol. 6, No. 3, September 1974

164 Daniel G. Bobraw andBertram Raphael/'

"

I

/

"

obtained as special cases of this newINTERLISP capability.

Anotherfeature of the INTERLISP frame isthe exit-function. In any system thatimplements flexible control structures,when a module makes a normal return to itsparent, certain bookkeeping operations mustbe performed by the system during theactual transfer. INTERLISP provides a placein the frame for a user function to bespecified for execution at this time. Thisexit function may be specified at run timeby a different module. Thus,for example, amodule can insert an exit function in themodule three above it in the control chainwhich causes a breakpoint to the user justbefore that higher module returns to itsparent.

Because QLISP was first implementedbefore the new INTERLISP featuresmentioned above were available to buildupon, a method for "recursive" backtrackingwas implemented; that is, one canbacktrack to a higher point in a depth-firstcontrol tree. In this mode once a QLISPexpression exits with a value, thatexpression cannot be re-entered as agenerator to produce another value.However, as Snssman pointed out, mostsequential backtracking programs can berewritten into more readable nestedrecursive tests. BIS is the recursivebacktracking version of the QLISPassociative retrieval program IS. IS takes apattern as its argument, and tries to find aninstance of that pattern in the data base.BIS takes as an additional argument a testfor any expression found. If a proposedexpression is rejected, BIS attempts to find adifferent instantiation of its patternargument. For example, the followingprogram will search the data base forsomething that John owns which is coloredred: (The pattern-matching operations areexplained furtherin Section C.)

(BIS (OWNS JOHN -X)

(IF (IS (COLOR $X RED))THEN (PRINT $X)ELSE (FAIL)))

trigger each demon, or a more carefreesystem, in which he calls for all demons atevery opportunity.

4. POPLER/POP'S. POPLERI.S followsthe PLANNER philosophy in terms ofmaking a failure mechanism andbacktracking an important part of thecontrol facility. It uses the Bobrow and"Wegbreit frame structure model and allowsgeneral multiprocessing to be programmedwith primitives similar to the onesdescribed for CONNIVER and INTERLISP.The POPLER interpreter does the time-sharing quantum management. Data-basedemons are modelled directly on PLANNER.

Its special additional fields for the moduleframe are an updateable frame data itemwhich can be accessed by the user, a frametype which specifies certain continuationproperties of the procedure, and an actionlistwhich is used for the backtrack controlscheme. The action list contains failureactions which are executed whenbacktracking occurs, and exit actions whichare executed when a POPLER functionreturns via its control link. The latterprovide the same facility as the exitfunction of INTERLISP.

These extended control facilities are onlyavailable in POPLER, and not in theunderlying POP-2. However, POP-2 doesprovide a more basic facility in which thiscontrol regime is written. Standardfunctions enable saving part of the currentstate of the POP-2 system (below a presetbarrier). These are directly useful in doingstandard backtracking, but require moreextensive programming such as Was done inPOPLER to provide the full environmentmanipulation. As simply implementable,straightforward functions, the POP-2primitives are a reasonable step towardfully programmable control structures.

Demons, in current QLISP, are set up asgroups of functions called teams that maybe associated with any net storage orretrieval command. This gives theprogrammer-the flexibility needed to designeither an efficient system, in which hecarefully selects the appropriate times to

C. Pattern Matching

In this section we shall describe theprincipal automatic pattern-matching andvariable-binding operations of the newlanguages.

ComputingSurvcjs, Vol. (i, No. 3, September 1974

i New Programming Languagesfor Artificial IntelligenceResearch 165"

"

1. SAIL. SAIL does not use templates or aspecial variable notation for pattern-matching. Following normal ALGOLconventions, variables in SAIL must bedeclared with their types. Item variables oritemvars, represented by identifiers, namelocations that may have SAIL items as theircontents. These contents (also referred to asthe values of the itemvars) are frequentlydetermined by a search and match operationInvoked by a FOREACH statement. Forexample, if x and y are itemvars, thestatement

FOREACH x,y SUCH THATrather « x « yDO ...

will cause the template

father a

to be matched against all triples in the database that begin with "father", call thesecond and third elements of each suchtriple x andy, respectively, and execute theprogram specified after the DO for each suchpair. Thus, patterns per se, as datastructures, do not exist in SAIL. Rather, theprogram syntax simultaneously specifiesseveral patterns and uses them to retrievedesired itemsfrom the data base.

2. PLANNER/CONNIVER. PLANNER andCONNIVER (and QLISP) use templateswritten in "inverse quote mode"; that is, allidentifiers are assumed to be constantsunless marked by a prefix to be a variable.The specific prefix used identifies the typeof binding the variable may take. Theprefixes for each language are indicated inparenthesesafter the type name.

PLANNER has two types of patternvariables, open ($?) and semiopen (s*), plussome standard matchers (e.g., ? matches anyone item, without setting any variable). Inpresent implementations, pattern matchinginPLANNERcan only instantiate variables atthe top level of the data list structure. Thisdoes not seem to be a serious constraint,primarily because patterns are only matchedagainst assertions, and PLANNER assertionsrarely have more than one level ofstructure.

CONNIVER uses pattern matching in muchthe same way as PLANNER—to fetch itemsfrom the data base, or to identify applicableprograms by their patterns. CONNIVER hasvariables of type open (?), macro ("," which

substitutes the CONNIVER value, and 9which substitutes the LISP value in thetemplate) and several types of restrictedvariables (! restricts the variable to matchItems not containing any variables). TheCONNIVER pattern matcher may be used onarbitrary LISP data and may containvariables at any level, and as a tail of a list.For example, thepattern

((FREDS ?X) . 7REST)

matches both

((FREDS FATHER) WHISTLES)

((FREDS GONE) HESAID),and

generating association lists

((X FATHER) (REST (WHISTLES)))

((X GONE) (REST (HE SAID))).and

3. QLISP/INTERLISP. Pattern matchingplays a much more important role in QLISPthan it does in the previously discussedlanguages. Patterns are used here not onlyto access the data base and to selectappropriate functions (by means of goaJstatements or other demon constructs), butalso as a basic method for operating uponcomplex data structures.

QLISP variables come In three varieties:Open (-), semiopen(?), and closed ($); and inindividual and segment modes (segmentmode variables are prefixed «»♦■, ??, and $$,respectively).

QLISP functions resemble LISP functionsbut, instead of a list of bound variables toassociatewith actual arguments, the lambdaexpression begins with a pattern to bematched against the actual argument.(QLISP functions have only one argument,but this can be an n-tuple.) Patternextraction eliminates the need for possiblyconfusing chains of cars and cdrs. Forexample, suppose we want a program totransform a list structure of three elementsin the following way:

(A (B C)) should become ((C B) A).

The LISP function to do this would be:

(LAMBDA (X)(LIST (LIST (CADADR X)(CAADR X))

(CAR X))).

Computing Surveys, Vol. fi, No. 3, Sepiem!x»r 1!J74

166 Daniel G. Bobrow andBertram Raphael

"

(

"

laQLISP it would be more transparent:

(QLAMBDA (TUPLE «-X (TUPLE *V *Z))(TUPLE (TUPLE $Z $V) $X)).

Moreover, if the actual datadid not have theappropriate form, e.g., if we tried to runthese programs on the lists

(A B C) or

(A (B C) (D E)),

theLISP program would generatean erroratsome lower level that might be difficult todiagnose, or (in the second example) itwould calculate a meaningless result thatwould cause some future program to runinto trouble; the QLISP programimmediately reports that its argument doesnot have theanticipated structure.

Now we can see how the pattern-matching technique for labelingsubstructures of an expression isparticularly useful for QLISP structures ofmixed data type. Suppose we wish to findan expression that plays some special role inan arbitrary set of algebraic expressionssuch as

This set could berepresented In QLISP by

(CLASS 17(TUPLE DIFF A B)(TUPLE PLUS (BAG SCDE))(TUPLE PLUS (BAG C B D))(TUPLE DIFF D A)).

Now let us pose the question, "If anynumber is subtracted from something in oneexpression and added to something inanother, tell me what it is added to." Whenmatched against the above set, the followingpattern

(CLASS(TUPLE DIFF -VI -V2)(TUPLE PLUS (BAG -V2—X))«—V3)

will cause the variables to be bound asfollows:

X (BAG C D)VI AV2BV3(TUPLE (PLUS (BAG SCD E))

(TUPLE DIFF D A))Note that order in a class is not important in

the match, and «-»-V3 is necessary sinceevery pattern mustmatch exhaustively.

4. POPLER. Pattern matching inPOPLER isused for the same purposes as inPLANNER/CONNIVER. Pattern variables inPOPLER have four types, two modes, andrestrictions for any of the types. Therestrictions include a data-type restriction,and user programmable tests. The types aretwo forms of open variables (#* whichpermanently assigns values, and #: whichtentatively assignes a value, setting up afailure action to restore the old value in caseof later failure back), a closed variable (##),and a semiopen type (#> which is acombination of #: and ##). In matching liststructure elements, variables can have asegment mode (prefixed with ###,#", #:t,and #>>, respectively), and match aninterior segment of a list.

POPLER patterns are very general, withvariables at arbitrary levels in a list, and astock of standard pattern "matchers" whichhelp specify the pattern. These include amatcher which tests whether a specifiedlist is contained in the target, one whichwill check property lists, and combiners toallow alternatives and conjunctions. Newmatchers are easy to add.

D. Deductive Mechanisms

In this section we shall describe theprincipal automatic search, deduction ordecision-making facilities for the newlanguages.

1. SAIL. SAIL does not have any explicitdeduction mechanism. However, complexsemi-automatic search procedures thatimplement certain deductive principles caneasily be programmed with the aid of adevice called a "matching procedure". Amatching procedure is a boolean procedurethat may contain unbound pattern variablesas arguments. The matching procedure iscalled from a FOREACH enumerationstatement. It returns either by succeedingand returning values for the previouslyunbound parameters, or failing, whichcauses theFOREACH to terminate.

For example, suppose we wish toexecutesome program hum for every known part of

Computing Surveys, Vol. 0, No. 3, Srpieinlwr 1074

{17, a-b, s+c+d+e, c+b+d, d-a}.

New Programming Languagesfor Artificial Intelligence Research/' 167

"

"

a human being. If the data base hasassociations such as

part e> human = handpart ® human « footpart o hand = fingerpart a finger = fingernailpart a foot * toe

The statement

FOREACH x SUCH THATpart ® human = xDO hum

would only run hum on hand and foot.However, the following use of a recursivematching procedure partof would run humon all parts of the human, because partofspecifies the desired transitivity of the partrelation:

FOREACH x SUCH THATpartof (human,x)DO hum

Here is a definition of partof, withcommentsenclosed in quotes:

MATCHING PROCEDURE partof(itemvar a t?itemvar b);

"The question mark indicatesa possiblyunbound parameter"

BEGINFOREACH b SUCH THATpart o a 'b DOBEGIN SUCCEED; "pass back as first

answer each value of b foundby direct memory look-up"

qt-biFOREACH 6such that partof(q,b)DO SUCCEED;

"Recursive call fortransitivity; whenever any bis found, it is passed back tothe caller."

END; "Outer FOREACH now iterates.1FAIL; "No more possible answers."

END;

2. PLANNER/CONNIVER. The key to thedeductive mechanism of PLANNER is thetheorem, an expression containing as majorelements a target pattern we shall call P anda program Q. There are three categories oftheorems: consequent, antecedent, anderase. These categories differ primarily inthe ways theyare invoked.

The most important category with respectto deduction is the consequent theorem,which usually has the logical form

Q implies P;

that is, "if program Q were successfullyexecuted then the assertion matched bypattern P would be proven". Frequently the"program" Q itself merely requests that anassertion be proven, so that the consequenttheorem sets up an automatic backward-chaining mechanism for searching the database.

These searches are initiated by the goalstatement. For example, suppose someprogram wishes to determine whether afinger is part of a person, "when the database contains the assertions(PART ARM PERSON), (PART HAND ARM) and(PART FINGER HAND). The programstatement

(GOAL(PART FINGER PERSON))

would first look directly for the assertion(PART FINGER PERSON) in the data base, butnot find it; then the goal mechanism wouldlook for a consequent theorem whosepattern matches the assertion of the goal. Ifthe theorem

[CONSEQUENT(PART $?X $?Z) [Pattern P]

(GOAL (PART $?X $?Y)) r_ -(GOAL (PART $7Y $?Z))j LPr°g*ani QJ

is stored in theorem memory, then bymatching

(PART $?X $?Z)

against the goal (PART FINGER PERSON) thetheorem would "run", i.e., attempt to prove,two new instantiated goal statements:

(GOAL (PART FINGER $7Y))and

(GOAL (PART $?Y PERSON)),

Upon matching the first goal against thedata base, V is Instantiated as HAND; thesecond goal can then be satisfied by anotheruse (a recursive call) ofthe same consequenttheorem.

The above example shows how factsimplicitly present in the combined data baseand theorem memory can be deduced whenneeded. An alternative approach to making

Computing Surveys, Vol. fi, No. 3, September 1974

Daniel G. Bobrow andBertram Raphael168

"

(.:

"

needed facts accessible is to deduce them atthe earliest opportunity and store themexplicitly for future possible use. Thisapproach is possible in PLANNER ~by usingantecedent theorems.

Whenever anything is asserted, i.e.,addedto the data base, all antecedent theorems arechecked against the new assertion. If the Ppart matches the assertion, the Q part isimmediately executed.

Suppose we havethe following theorem:

[ANTECEDENT(PART $?X $?Y) [Pattern P}

(GOAL (PART $7Y $?Z))rPl",":hi

(ASSERT (PART $?X $7Z))) rogram UJ

Now,continuing the above example, ifsomeprogram executes

(ASSERT (PART FINGERNAIL FINGER))

then Por the above theorem matches, so thetwo-statement Q is automaticallyinstantiated and executed. First(GOAL PART FINGER $?Z)) is proven fromthe data base by setting Z to HAND, and then(ASSERT (PART FINGERNAIL HAND)) isexecuted. This latter assertion againinvokes the same antecedent theorem.Eventually

(PART FINGERNAIL ARM)

and

(PART FINGERNAIL PERSON)

are also added to the data base, eliminatingthe need for deducing these facts (withconsequence theorems) if they are everneeded in the future. Of course, antecedenttheorems must be used judiciously to avoidcluttering up the data base with manyrelatively useless facts.

The third PLANNER theorem type is erase:Its Q part is executed whenever P matches afact that is being erased (deleted) from thedata base. Just as antecedent theorems,which are triggered by assertions, areusually used to assert additional derivedfacts, erase theorems, which are triggeredby erasures, are usually used to eraseadditional dependent facts in order to cleanup the data base.

CONNIVER takes the view that PLANNERtheorems and their associated search or

data-manipulation activities are tooautomatic. Instead of offering, for example.a GOAL mechanism that searches throughalternative derivations (by means ofconsequent theorems) until a final proof isfound. CONNIVER gives the programmermechanisms for designing his own searchalgorithms. These mechanisms can be usedto construct algorithms similar to the onesbuilt intoPLANNER. If desired, but they alsopermit much more flexible communicationand dynamic modification of the searchprocedures.

CONNIVER data items each reside in theirown named data contexts; each majorelement of a CONNIVER search algorithmalso resides in its own control context. ThePLANNER concept of pattern-directedprogram invocation—embodied in the P andQ elements of every PLANNER theorem—hasbeen carried over into CONNIVER. However,the process of matching the pattern P, togenerate data items and to bind variables,takes place in a control context independentfrom the program Q that makes use of thosebindings. The two processes may beinterleaved in any manner desired by theprogrammer, who is given convenienthandles for coordinating andcommunicating between such processes.Thus, although there are no built-indeductive mechanisms quite likePLANNER'Stheorems, CONNIVER makes it easy for aprogrammer to devise his own, more tightlycontrolled, deductiveprocedures.

3. QLISP/INTERLISP. The QLISP goalstatement is quite similar to the goaistatement of PLANNER; it causes first asearch through the data store for an itemmatching the argument of the goal, andthen, if that search is unsuccessful, the goalstatement invokes the execution ofappropriate functions (programs) whosetarget pattern matches the goal. EveryQLISP function has aspart of its definition a"bound variable expression" that contains apattern that is matched against its argumentbefore the function may be invoked. Thispattern filters out inappropriate arguments,and it binds variables within the functiondefinition to appropriate elements of theselected arguments. As in PLANNER, QLISPfunctions also maintain appropriate controlinformation to backtrack automaticallythrough alternative matches until a goal issuccessfully completed. (By QLISPfunctions we mean the new QLAMBDA form

Computing Surveys, Vol. fi, No, 3, September 1974

New Programming Languagesfor Artificial IntelligenceResearch 169i.

"

"

which has been added to the repertoire offunction types available in INTERLISP.)

In addition, the QLISP goal statement hasseveral features thatare oriented somewhatdifferently from the comparable PLANNERstatement:

a) The goal statement consists of twodistinct operations in sequence: adata base search, followed by thepattern-directed execution ofprograms. These two operations,called is and cases, respectively,are commonly usedindependently.

b) SAIL normally only stores truepropositions (assertions) in itsmain permanent data base.Although any expression may bestored in the PLANNER data base,the built-in GOAL searchmechanism assumes they allrepresent assertions. AlthoughPLANNER assertions may haveproperty lists, these are not usedby the system in any standardway. QLISP encourages theprogrammer to put in the net anycomplex structures he wishes;each has a uniqueoccurrence, anda property list. In following goalchains, QLISP system functionsknow that assertions are justthose net expressions that have ontheir property lists aMODELVALUE attribute withtruth value T (true) or NIL(false).

c) The QLISP demon mechanism isimplemented by requiring theuser to specify teams of demonfunctions (perhaps none) as partof every data storage or retrievaloperation. By specializing thesedata operations, eg., one forchanges to the robot world,another for logical propositions,the team mechanism allowstighter specification of relevantdemons. Standard teams forASSERT and DELETE couldimplement the PLANNERantecedent anderase theorems.

d) Like CONNIVER, QLISP has both dataand control contexts which maybe created or modified by theprogrammer. Goal statements maybe executed with respect to anyspecified contexts; therefore data-

base changes need not be undoneas in PLANNER, with erase andantecedent theorems. As theapplicable scope of an expressionchanges, CONNIVER permitsmoving of expressions to othercontexts. QLISP will be able toperform asimilar function.

4. POPLER. The POPLER deductivemechanism is modeled after PLANNER andCONNIVER, with procedures which can becalled by "pattern-directed invocation". Atarget-pattern, representing what is to bedone, is used to select a procedure whoseprocedure pattern matches the target-pattern. There are four types associatedwith different classes of targets: achieve,infer, assert or erase. Assert proceduresare like the "antecedent theorems" ofPLANNER, invoked when appropriate dataitems are added to the data base; eraseprocedures operate when items areremoved.7i?/erand achieve procedures correspond totwo different PLANNER uses of "consequenttheorems"; the infer type checkwhether something is now the case, versus,the achieve type which try to makesomething be the case. Inferring does notallow the use of operators which areknownto change the world. To use Davies example(1973 p.7.1), in a chess playing program weshould certainly want to distinguishbetween the target statements:

1) achieve([l am checkmated]);

2) infer([l am checkmated]);

The former would attempt to lose the game,while the latter only checks whether thegameIs already lost.

In addition to direct invocation ofrelevant procedures with backtrack control,POPLER allows the CONNIVER-likeconstruction of a possibilities listindependent of the invocation of theprocedures. Possibilities can be procedureitems or generators, and can be pruned byanyfunction with access to thispossibilitieslist. POPLER also allows user association ofrecommendation lists and filters to helpmodify the straightforward (default) depthfirst search.

V CONCLUSIONS

We have describedin this paper aspects ofseveral new programming languages for AI

Computing Surveys, Vol. ti, No. 3, September 1974

170 DanielG. Bobrow and Bertram Raphael r

"

(

"

research. We shall nowreview some of theprincipal features and present status ofthese languages:

(1 ) SAIL. This language isone of the moststable, debugged, and heavily used of thelanguages surveyed. It runs on a PDP-10under the DEC 10-50 monitor. Its ALGOLbase provides full algebraic capability, withwell-tested I/O and interface to assembly-language subroutines. The debuggingfeatures remain an extension of an assemblycode debugger. Swinehart (1973) hasimplemented a display package for a systembuilt on top of SAIL which allowsinformative exploration of a controlstructure tree. The associative memory is asingle, permanent, top-level structure; noconvenient way exists for partitioningaccess to the associations on the basis ofcontrol context, subject matter, etc., exceptby explicit programming. Major storagemanagement, including erasure ofabandoned data, is the programmer's (ratherthan the system's) responsibility; so is thespecification of which variables to save orrestore upon backtracking. Fairly elaborateprocess control and communication featureshave recently been added to the language,and It seems likely that the language willcontinue to be modified in an evolutionarymanner torespond to the needs of its users.

and there is no convenient way to make useof the knowledge that a given proposition isfalse. PLANNER has received muchpublicity, partly because of the outstandingresearch for which it is being used at theMIT Al Laboratory. Its future probablydepends upon the efficiency of its newimplementations and the experiences of agrowing community of users.

(3) CONNIVER. This new system grew outof the collective experience of MICRO-PLANNER users. It to© is implemented inLISP under ITS. The philosophy ofCONNIVER is to return a much greaterdegree of control—and responsibility—tothe user than was permitted by PLANNER.As a result, CONNIVER is a system inwhichit is possible for skilled programmers todesign efficient algorithms that involve thekind of complex interacting processesneeded in current AI research. SinceCONNIVER does not have PLANNER-likeconventions tostructure thesemantics of itsdata and programs—assertions, theorems,goals, etc.—it may be substantially moredifficult for a new user to learn. On theother hand, the inefficiencies of blindbacktracking may make PLANNER also animpractical language except in the hands ofan expert who learns the subtleties of itsmore complex control options.

(2) PLANNER. MICRO-PLANNER is animplementation of a subset of Hewitt'sPLANNER ideas (Hewitt 1972). MICRO-PLANNER was written in LISP under theMIT ITS system that runs only on thePDP-10 at MIT, but MICRO-PLANNER hasbeen transferred to other LISP systems forexperimental use. PLANNER Introduced theimportant coupled concepts of pattern-directed program selection and proceduralrepresentation of knowledge. Extensiveautomatic depth-first search and backtrackcontrol is a debatable feature of PLANNER:this automatic control structure permits theprogrammer to describe his algorithms in apiecemeal declarative fashion withoutworrying about sequential program flow;but it can lead to highly inefficientthrashing in the absence of suitableconstraints, and the right constraints arefrequently awkward to express. Thenatural conventionsfor using the data storeasssume that it holds only elementarypropositions that are presumed to be true;there are no built-in checks for consistency.

(4) QLISP/INTERLISP. Much of the QLISPphilosophy, and large chunks of its actualcode, were taken directly from QA4, anexperimental language implemented at SRImore than two years ago. The usefulness ofQLISP's new data types and pattern-matching facilities Were tested in QA4 inproblem-solving and automatic-programming research. The majorshortcomings of QA4—such as slowexecution and lack of debugging tools andutility functions—have been overcome byembedding QLISP directly into INTERLISP.All the well-established capabilities ofINTERLISP debugging aids, user filestructures, and so on, as well as all of basicLISP, are automatically available. The new-control features of INTERLISP nowbecoming available will help to make thecombined INTERLISP/QLISP system one ofthe most flexible systems available. QLISPIs still under active development and a firstversion of QLISP has been completed at SRIwith preliminary versions in experimentaluse for a year. A new version of the pattern

Computing Surveys, Vol. (V, No. 3, September 1974

New ProgrammingLanguagesfor Artificial IntelligenceResearch 171"

"

matcher that gains generality by using aunification-like algorithm is being addedand substantial changes may take placewhen QLISP is fully integrated with thenew control structure implementation forINTERLISP. QLISP will eventually containan efficient implementation of most of thedesirable language features we havediscussed, and will be available to the large,interested community of DEC PDP-10TENEX system users.

(6) POPLER. POPLER 1.5 is a programminglanguage implemented in and an extensionof POP-2, a system developed at theUniversity of Edinburgh for application toArtificial Intelligence programming. POP-2has been used for several years on the ICL4130 in Edinburgh; In the past year aPDP-10 implementation has been completed(for the 10/50 monitor), and others havebeen started. Recently a new interactiveeditor has been completed, and the system iswell documented and friendly to users.POP-2 is a simple programming language-with good data structure facilities: built-inwords, arrays, strings, lists and records. A"garbage collector" automatically controlsstorage for the programmer.

POPLER 1.5 was completed in spring1973, and has not yet been used for anymajor projects. It looks like it will providamost of the facilities of a PLANNER likesystem. It has a sophisticated controlstructure which is "visible" to theprogrammer and program. Programscan becompiled into POP-2 or kept in datastructures and interpreted by a specialevaluator. The language has generalfacilities for pattern matching, patterninvocation of procedures, and pattern-directed retrieval from a context structureddata base. The principal problem withPOPLER stems from the fact that it is builton top of POP-2 and is not integral with thesystem. Another problem is that itcurrently works only in Edinburgh, and thefolklore of thesystem is in very few hands.

The languages wediscussed above are theprincipal systems currently in use, or likelyto be" in use in the near future, at the largestAI laboratories. Among them, they representthe major new directions in thedevelopment of AI software tools. Severalother experimental language systems havesome features in common with the systems

we have surveyed. We did not include suchother systems in detail in this paper becauseeither the system was purely experimentaland unlikely to see extensive use, thefeatures of AI interest are only incidental tothe main functions of the language, or wewere not sufficiently familiar with thesystem to treat it accurately here.Nevertheless, the reader may be interestedin learning more about at least thefollowing relevant systems:

(1) ABSET (Elcock et al 1971), aprogramming language based onsets, developed at the Universityof Aberdeen;

(2) ECL, an extensible language systemdeveloped(Wegbrelt et al 1972) atHarvard University for work inautomatic programming. Similarto INTERLISP internally, it hasparticularly good handling ofextended data types. It combines apleasant source language, aninterpreter for list structurerepresentation of programs, andseveral levels of optimizingcompiler. It has been working forabout a year,

(3) LISP-70 (Tester et al 1973), acompiler based LISP systemdesigned to be a "productionlanguage" for AI, that is, it biaseslanguage features towardefficient implementation. Thefull system is not yet up, but aprototype MLISP2 (Smith & Enea1973) used some of the patternmatching and automatic rulemaintenance for some naturallanguage processing work.LISP-70 looks as if it will be aninteresting language when it isfinally available.

(4) SMALLTALK (Kay et al 1973) andPLANNER73 (Hewitt et al 1973).both embody an interesting ideawhich extends the SIMULA(Ichbiah Sc Morse 1971) notion ofclasses, items that have bothinternal data and procedures. Auser program can obtain an"answer" from an instance of aclass by giving it the name of itsrequest without knowingwhether the requestedinformation is data or isprocedurally determined. AlanKay has extended the idea by

Computing Surveys, Vol. 6, No. 3, September 1974

Daniel G. Bobrow andBertram Raphael172

"making such classes be the basisfor a distributed interpreter inSMALLTALK, where each symbolinterrogates its environment andcontext to determine how torespond. Hewitt has called aversion or such extended classesactors, and has studied some ofthe theoretical implications ofusing actors (with built-inproperties such as intention andresource allocation) as the basisfor a programming formalism andlanguage based on his earlierPLANNER work. AlthoughSMALLTALK and PLANNER73 areboth not yet publicly available,the ideas may provide aninteresting basis for thinkingabout programs. The majordanger seems to be that too muchmay have been collapsed into oneconcept, with a resultant loss ofclarity.

The development of software tools for AIresearch is currently an extremely activearea, and the systems emerging from thisactivity are still in a great state of flux.However, one can begin to see the featuresfitting together. For example, current AIresearch interests in representation ofknowledge demand the availability ofpermanent associative memories andcomplex symbolic structures formed fromnew data types such as sets. Thesestructures almost force the use of pattern-based analysis and retrieval methods.Pattern matching applied to such data, inturn, is highly likely to be ambiguous andthus suggests backtrack control. Thesimultaneous availability of all thesefeatures results in extremely parsimoniousdescriptions of current AI algorithms.Within the next few years we expect that

one or more successors of QLISP,PLANNER/CONNIVER, POPLER, and similardevelopmental efforts will stabilize andbecome themedia for the major AI resultsofthe next decade. Such successors willembody not only the new features describedhere, but will face up to the programmingprocess as an entity (as described in Bobrow1972), and provide the programmer the

tools necessary to facilitate all hisinteractions in building a working system(e.g.. editing, debugging, optimization,documentation,etc.).

Programming languages for artificialIntelligence have often been a provingground for new language and data formswhich later become part of the generallanguage stream. The conditionalexpression invented by McCarthy for LISPfound its way first into ALGOL and becamewidespread. List processing primitives fromIPL and LISP are now in PL/I etc. Some ofthe new features described here will alsoundoubtedly find*thelr way into the mainstream of business and scientific computerprogramming languages. As data basesbecome more symbolic (less numberoriented) and moredynamic, something likecontent-directed retrieval with pattern-matching and pattern-directed invocationwill become necessary. Of course, COBOLhas provided file structuring and readingoperations for some time, and the CODASYLreport a standard for data retrieval, butmoreis required for the integration of data basemanagement with an incrementallychanging library of routines for makinginferences from the data. For more flexiblestructuring or system processes,programmers will want to program theirown flow of control. Finally smarterdebugging, editing and program-verifyingtools now built into some Ai languages willsomeday help programmers in many fieldstoconstruct correct programsfaster.

c

BIBLIOGRAPHY

Baumgart, B.G. Micro-Planner Alternate Reference Manual. Stanford AI LabOperating Note No. 67, April 1972.

Bobrow, D.G. Requirements for Advanced Profranwinfl Languages for ListProcessing Applications. Contnunications of the ACH. Voluat* 15, Number 7,pp. 618-627, July 1972.

Bobrow, Daniel G. and Raphael, Bertram. A Comparison of List-ProcessingComputer Languages. Coramin teations of the ACH. Volutse 7, Number 4, April1964.

"Coroputiog Surveys, VoJ. 0, No. 3, September 1274

New Programming Languagesfor Artificial IntelligenceResearch 173"

#

Bobrow, Daniel G. and Wegbreit, Ben. A Model and Stack Implementation ofMultiple Environments. Communtca tions of the ACM, Volume 16, Number 10 p39, October 1973.

Bobrow, Daniel G. and Wegbreit, Ben. A Model for Control Structures forArtificial Intelligence Programming Languages. Proceedings of IJCAI3, p.16, Stanford, California, August 1973.

Burstall, R.M., et al. Programming in Pop-2. Edinburgh University Press, 1971.Carbonell, Jaime R. and Collins, Allan N. Natural Semantics in Artificial

Intelligence. Proceedings of IJCAI3, Stanford California, August 1973.

Davies, D. Julian M. Popler 1.5 Reference Manual. University of Edinburgh , TPUReport No. i, May 1973.

Elcock, E.W. et al. Abset, A Programming Language Based on Sets: Motivationand Examples. In B. Meltzer and D. Michie (Eds.), Machine Intelligence 6,Edinburgh University Press, 1971.

Feldman, J.A. et al. Recent Developments in Sail—An Algol-based Language forArtificial Intelligence. FJCC, 1972.

Feldman, J.A. and Rovner, P.O. An Algol-based Associative LanguageCommuni cot tons of the ACM. Volume 12, Number 8, pp. 439-449, August 1969.

Gelernter, H. and Rochester, N. Realization of a Geometry Theorem-provingMachine. Proceedings of the International Conference on InformationProcessing. Paris, Unesco House, 1959.

Griswold, R.E. et al. The Snobol4 Prograrming Language. Prentice-Hall, 1968.

Hewitt, C. Procedural Embedding of Knowledge in Planner. Proceedings ofIJCAI2, London, September 1971.

Hewitt, C. Description and Theoretical Analysis (Using Schemata) of Plannert ALanguage for Proving Theorems and Manipulating Models in a Robot. AI MemoNo. 251, MIT Project MAC, April 1972.

Hewitt, C. et al. A Universal Modular Actor Formalism for ArtificialIntelligence. Proceedings of IJCAI3, Stanford, California, August 1973.

Ichbiah, J.D. and Morse, S.P. General Concepts of the Simula 67 ProgrammingLanguage. Compagnle Internationale pour l'lnformatique, Paris, September1971.

Kay, A. et al. Smalltalk Notebook. Xerox Palo Alto Research Center, 1973

McDermott, Drew V. and Sussman, Gerald Jay. The Connioer Reference Manual. AIMemo No. 259, MIT Project MAC, May 1972.

Reboh, Rene and Sacerdotl, Earl. A Preliminary Qlisp Manuel. SRI AI CenterTechnical Note 81, August 1973.

Rulifson, J.F., et al. QA4, A Language for Writing Problem-solving ProgramsProceedings IFIP Congress, 1968.

Rulifson, J.F. et al. QA4t A Procedural Calculus for Intuitive Reasoning. SRIAI Center Technical A^ote 73, November 1973.

Smith, D.C. and Enea, H.J. MLISP2. Stanford AI Lab Memo AIH-l95, May 1973.

Sussman, Gerald Jay and McDermott, Drew Vincent. From Conniver to Planner,Genetic Approach. Proceedings of the FJCC, 1972.

Sussman, G.J. and Winograd, T. Micro-planner Reference Manual. AI Memo No203, MIT Project MAC, July 1970.

Computing Surveys, Vol. fi. No. 3, Scptemlw»r 1074

174 Daniel G. Bobrow andBertram Raphael

"

(

»

Swinehart, D. A Multiple-process Approach to Interactive Programing Systems.PhD Thesis, Stanford University, 1973.

Swinehart, D. and Sproull, B. SAIL. Stanford AI Project Operating Note No.57.2, January 1971.

Teitelman, W. Toward a Programming Laboratory. Proceedings. IJCAI 1,Washington, D.C, 1969.

Teitelman, W. Interlisp Reference Manual. Xerox Palo Alto Research Center,1974.

Tesler, L.G. et al. The Lisp7o Pattern Matching System. Proceedings IJCAI3,Stanford, California, August 1973.

Wegbreit, Ben et al. ECL Programmer's Manual. Harvard University, September1972.

Copyright © 1974, Association for ComputingMachinery, Inc. General permission to republish,but not for profit, all or part of this material isgranted, provided that ACM's copyright notice isgiven and that reference is made to this publica-tion, to its date of issue, and to the fact thatreprinting privileges were granted bypermission ofthe Association for Computing Machinery.

('iimpiiliflKSurvey.*, VnJ. fi. No. 3, Sfptfinlier 1074