/

File under: S

Name: Stephen Westfold

Time: 0:51

*;<»^>"4>;<>,'<>:<>>o»:*>;4iii>;<»:<»:<>:«»:«>>^4t;<>;«»;i>:t»;«j>>;«>^>^^»:<>;<»;<»;<»;<>^>;»t:i>:ti;<»;<»^>:i>:<»:i^

&, FOR DELIVERY TO JACKS HALL row******>:<i:»:»;<»;»:»j>:»:»:»wt:« Please place in bin for Margaret Jacks Hall >:<>:»m>:<>:»:<>:»;»:<>:<>:<

Date: 15 Jun 1979 Name: Stephen Westfold

Project: 1 Programmer: SJWFile Name: AIL2.XGP[AIH,SJW]

File Last Written: 0:45 15 Jun 1979

Date: 15 Jun 1979

Stanford UniversityArtificial Intelligence Laboratory

Computer Science DepartmentStanford, California

1AI Languages

An Historical Overview of Artificial Intelligence Programming Languages

Stephen Westfold

Artificial Intelligence programming languages have had a central role in the history ofArtificial Intelligence. They have two important functions. First, they allow convenientimplementation of programs demonstrating and testing AI ideas. Second, they provide vehicles ofthought; as with other high-level languages, they allow the user to concentrate on higher levelconcepts and avoid being distracted by low-level implementation details. In this article wedistinguish between the general-purpose languages widely used in AI, such as LISP and POP-2, andthe higher level AI languages, such as PLANNER and QLISP. Using the concepts of the higherlevel languages imposes a structure on the way one thinks, which can be restrictive, but withoutsome such structure it is very difficult to approach the problems of AI. Frequently, new ideas in AIare accompanied by a new AI language in which it is natural to apply these ideas. Usually, such ahigher level language is built on an existing high-level AI language so that the desirable features ofthe host language do not have to be re-implemented in the new language.

Figure 1 gives a rough indication of the directions in which AI languages developed and themajor influences on the languages.

IPL was developed around 1956 by Newell, Shaw, and Simon [] as the first programminglanguage specifically for AI. Its design was guided by ideas from psychology, especially the intuitionof association <more?>. The primary elements of the language were symbols as opposed to numbers,around which all other languages of the time were built. To form associations of these symbols, listprocessing was introduced. The objective was to enable programs to build data structures ofunpredictable size and shape conveniently. The problem of unpredictable shape was solved byusing data elements consisting of two fields, each of which could hold either a symbol or a pointer toanother such data element. This simple arrangement allows arbitrary binary trees or list structure tobe built. The problem of unpredictable size is handled by having i free list of data elements thatare allocated to the various data structures as required.

<should probably include a brief example of list structuro

A major advantage of list structure is that elements can be inserted and removed very simplyfrom existing structure. However, it is clearly desirable that elements deleted from all structures beavailable for reuse in new structure. In IPL the user is responsible for returning cells to the free listwhen they are no longer required. For programs that build complex structures that include somesharing of substructures, however, it is difficult to determine, in general, when an element is deletedfrom one structure whether it, or any structure it points to, is part of any other structure. Later listprocessing systems have therefore taken responsibility for reclaiming elements no longer used. Onemethod for doing this is to maintain a reference count for each element showing how many otherelements point to it. Every primitive list operation that deletes a pointer must decrement the countof the element pointed to and, if the count is zero, reclaim it and recursively delete any pointers fromthe element. An alternative method for reclaiming elements is garbage collection. Periodically, suchas when the free list is empty, the garbage collector traces all the pointers to elements accessible tothe program. Tracing a pointer consists of marking the element pointed to and recursively tracingthe pointers of this element. This process ensures that all elements still in use are marked, so theunmarked elements can be collected and added to the free list. (This algorithm also serves as anexample of how desirable it is to allow recursive procedures in list processing). It turns out that

2AI Languages

there are some combinations of list operations where it is not feasible to maintain reference countscorrectly [MOSE ?], whereas garbage collection can still be applied.

Another feature of IPL is the generator, which is a procedure for computing a series of values.It produces one value each time it is called and is then suspended, so that it starts from where it leftoff the next time it is called, [see Control Structures section for more information] This idea was toturn up later in CONNIVER and similar languages.

of the programs of the early history of AI were written in IPL, in particular theMost version

IPL-V.

<The Logic Theorist (the first heuristic program)The General Problem SolverThe Newell-Shaw-Simon Chess ProgramEPAMFeldman's two-choice decision modelLindsay's SAD SAMGreen, et.al. BASEBALL ?Tonge's Assembly Line Balancing programQuillian's networks.REF-ARF>

19561957195819591960 ALGOLGO19611962 "19631964196519661967196819G9 LEAP

■

1970 .SAIL1971 POP-21972197319741975

Figure I. Historical chart of the development of AI languages. The dotted lines indicatemajor influences. The bold lines indicate stronger relationships.

3AI Languages

Many of the ideas of IPL went into LISP. Unlike IPL, a rather low-level language with asequence-of-instruction style although it was considered quite a high-level language at the time of itsinvention, LISP is a high-level language with an algebraic style inspired by, but different from, thealgebraic notation pioneered by FORTRAN. During the design phase of LISP, some of the LISPideas were implemented within FORTRAN leading to the language FLPL [GELE]. FLPL wascreated so that some of the features of LISP would be in a working system that could be used forwriting a plane geometry program [GELE]. FLPL will not be discussed further. The first dialect ofLISP to be widely used was LISP 1.5. In the late 1960s a number of new dialects of LISP weredeveloped to meet the demand for sophisticated programming aids. The most important of thesedialects are MACLISP and INTERLISP (derived from 940 LISP through BBN LISP). Anothersignificantly used dialect is UCI LISP, an extension of STANFORD LISP 1.6 (itself an extendedversion of LISP 1.5) developed at the University of California at Irvine. UCI LISP will not bediscussed further because its advanced features are basically a subset of those of INTERLISP.Other languages developed around this time were SAIL at Stanford and POP-2 at Edinburgh.SAIL is a version of ALGOL6O augmented by LEAP, an associative retrieval formalism. It wasintended especially for those AI applications, such as vision, that require fast arithmetic. POP-2 iscloser to LISP but with an ALGOL-like syntax and was designed to be suitable for implementationon medium-sized machines.

Toward 1970 a number of AI researchers developed formalisms to allow convenientexpression of special purpose procedural knowledge for controlling problem-solving and deduction -PLANNER and QA4. CONNIVER embodied a reaction against PLANNER, giving the AIprogrammer lower level control while still maintaining many of the ideas of PLANNER. QLISPbore a similar relation to QA4, thought to a lesser extent, with an additional motivation being thedesire to fit cleanly into the new version of INTERLISP.

A number of features first introduced in AI programming languages have been found to beuseful in Computer Science more generally and have been included in many programminglanguages. It is difficult to trace the source of ideas with much certainty; frequently the same orsimilar ideas occur independently at different times and places, so some people probably would notagree with some of the items listed below. Also, the list is not intended to be complete.

Probably the most important idea so far has been list processing. This is one of the basicideas of the area of data structures, with applications in many fields of Computer Science includingcomplexity theory, databases, operating systems, and compilers. An early addition of list processingprimitives to a more generally available language yielded SLIP, a subroutine package forFORTRAN [WEIZ 1963]. SLIP was used for some AI work but mainly for other fields. ListProcessing facilities were included in PL/1, based more on the primitives of IPL than the slightlyhigher-level ones of LISP. Most recent general-purpose programming languages, includingPASCAL, have flexible data structures such as records which owe much to the ideas of listprocessing. Garbage collection is typically used to manage the storage of such structures.

The designs of LISP and ALGOL overlapped in time, with McCarthy being involved withboth. McCarthy was influential in the decision to include both conditional expressions andrecursion in ALGOL6O, having already decided to include them in LISP.

Symbol manipulation has been critical for the field of algebraic manipulation. Indeed, manyof them, including MACSYMA [] and REDUCE [HEAR 19??], have used LISP as a base language.Some symbol manipulation facilities were included in the language COMIT developed around 1960[]. COMIT is primarily a string handling language with some features specially designed to help in

4AI Languages

the analysis of natural language text. It was used for some AI work. It has beenlarge extent by SNOBOL [].

superceded to a

The applicative style of programming, pioneered in LISP (also used insuggested by a number of people, including Backus [BACK 1978] to be a morethan the yon Neumann machine-oriented languages that currently dominate.

APL), has beenappropriate style

5AI Languages

1. LISP

LISP was conceived around 1958 by McCarthy as a programming language for AIapplications, in particular, for those based on the use of formal logic. The development of theprecise form of LISP was determined by an interplay of practical concerns and of theoretical andaesthetic considerations.

The particular planned programs that motivated the language were a plane geometry theoremprover [GELE] and McCarthy's Advice Taker [MCCA 1959]. Following is a list of some of theimportant design features of LISP, along with reasons they were included. The reasons revolvedaround what was required for the originally planned programs and for other smaller programs thatwere considered during the design process, in particular, a program for symbolic differentiation.

1 List Processing. The originally proposed programs required the representation of formallanguage sentences and the ability to perform logical inferences for which the listprocessing techniques of IPL were well suited.

2- Algebraic Notation. The algebraic notation of FORTRAN was seen to be convenient becausearbitrary subexpressions of sentences could be extracted using composition of primitiveextraction functions. <give examplo

Prefix Form. For internal use it is convenient to use prefix form rather than infix form,because for most applications it is necessary to know the main connective before decidingwhat to do with an expression. Thus, unlike almost all other symbolic systems, LISP isbased on prefix rather than infix notation. For example, the infix expression 4*A*X + s>:<Bis represented in the prefix notation of LISP as (PLUS (TIMES 4 A X) (TIMES 5 B)). Itis useful for a symbolic differentiation program to have the "PLUS" first because it needsto know that it is dealing with a sum before it can know how to deal with the subtermsinvolving "TIMES".

3.

Conditional Expression. McCarthy introduced the conditional expression (if then else) whenspecifying legal move routines for Chess in FORTRAN.

4

Recursive Functions. The recursive nature of the differentiation of algebraic expressionsmade it natural to use recursive functions. Thus, differentiating the expression (PLUS 4A (TIMES B X) X) can be done by recursively applying the function that doesdifferentiation to each of the arguments of "PLUS," returning the sum of the results

5,

achieved as the answer.

6. Functional Arguments. For expressing the above differentiating process it was convenient tointroduce the maplist function, which applies a given function to every element of a list.This required the introduction of functional arguments and a notation for functions; theX-notation invented by Church [CHUR 1941] was chosen.

7. Garbage Collection. It was difficult to include explicit erasure of abandoned list structure inthe natural definition of differentiation, so it was desirable for the system to collectabandoned list structure automatically. Reference counts could not be used because ofhardware limitations, so the idea of garbage collection was invented.

6

AI Languages

It became clear during the design stage that LISP provided a neater way of describingcomputable functions than did Turing machines or other methods used in recursive function theory.McCarthy considered it useful to have LISP expressions obey convenient mathematical laws to allowproofs of properties of programs to be constructed using normal mathematical methods. Thisobjective was made possible for pure LISP although for practical programming reasons, functionswith side effects were also included in the language implemented.

The universal LISP function eval was written to show that it was briefer and easier tounderstand than the description of a Universal Turing machine. Writing eval required arepresentation of LISP functions as LISP data. When it was realised that eval could be used as aninterpreter for the language, it was hand coded in machine language, and LISP was therebyavailable. A consequence was to freeze the specification of the language, in particular, the list formatof LISP programs, even though lists had never been the intended external format.

Following mathematical notation, LISP programs consist only of applicative expressions builtup from variables and constants using functions. Thus, LISP is strongly function oriented. Afunction call is written as a list with the first element being the function symbol or object and theother elements the arguments to the function. This orientation gives LISP a distinctly differentflavor than other programming languages. In fact, people who know other programming languagesfrequently have difficulty learning LISP, although many users coming from a mathematicalbackground find it at least as easy a first language to learn as other programming languages.

Over the two decades since 1959, LISP has been the dominant language in AI, being used indiverse systems, some of which are far removed from the type of system for which it was originallyenvisaged. There are many reasons for this dominance, and it is unclear which were the mostimportant. Some of the reasons are those described above, which influenced the design of LISP, butothers were somewhat incidental to the design and are discussed below.

LISP was the first high-level language that provided convenient symbol manipulation and listprocessing facilities (IPL provided these facilities but was a fairly low-level language). This factsuggests that LISP may have become entrenched because of the costs of people adjusting to newprogramming languages, even when a newer language is generally recognized to be superior, as hashappened with FORTRAN. The costs of changing to a new language have become more importantwith the introduction of large LISP programming systems, such as INTERLISP, which have manyuser facilities. A competing system would need to provide comparable facilities to lure users awayfrom such a system, and supplying such facilities would involve considerable expense.

LISP has proved an excellent language for interactive programming. The basic LISPstatement, a call to a function, is a convenient and very powerful command language. LISP lendsitself to writing programs incrementally:- functions can be defined incrementally, withoutdeclarations; data structures and variable names (atoms) can be created dynamically. Using theinterpreted form of functions, it is simple to make try-and-see modifications to functions. Theimplementors of LISP have tended to stay in fairly close contact with the users; the result has beenthat the LISP systems have tended to develop to meet the needs of the users. The simple frameworkof LISP has been accommodating to such developments down diverse dimensions.

The ability of LISP programs to obtain functions at run-time and to execute them using theLISP interpreter eval is a powerful facility, as is the ability to pass around and store functions. Themany user facilities provided in current LISP systems, which will be described in the followingsection, also rely heavily on these techniques and the ability to manipulate user programs easily.

7AI Languages

The simple correspondence between internal and external forms of LISP functions has proved to bean advantage particularly when it is desired to manipulate functions by other LISP functions, forexample, in list-oriented editors or in "smart" compile macros. This convenience has encouragedsystem builders to provide powerful tools to help users manipulate and manage their programs andhas allowed users to tailor the system to their individual requirements.

As well as being good for interactive programming, LISP has proved itself a good, convenientlanguage for programming in general. It is a powerful, concise language for expressing processes onarbitrarily sized and shaped list data structures, through recursion and conditional expressions. Theprogram need not take account of such details as memory management because these are handled bythe LISP system through such features as the garbage collector. Typically, distinct functions areused for distinct subproblems, which leads to modular programs. By defining functions to representthe operations that a programmer thinks of as basic, the main procedures can be written using thesefunctions as primitives and thus reflect the steps that the programmer has in mind. In this wayLISP can effectively be used to build higher level languages. Alternatively, it is easy to writeinterpreters of specially designed higher level languages represented as list structure. On the otherhand, the basic functions are at a low enough level so that the user does not often feel limited by thelanguage, and most implementations have allowed fairly convenient access to the machine andoperating system facilities.

8AI Languages

2. Current General AI Languages

The medium-level, general-purpose programming languages commonly used in AI are SAIL,POP-2, and several versions of LISP, particularly INTERLISP and MACLISP. A characteristic ofAI programs is that they tend to be large and complex. This fact has led to a demand forprogramming systems that provide extra support for developing and debugging programs. [Seesection on Environment] The various LISP systems have led the way in this direction because LISPhas been the dominant AI language and because it lends itself to interactive use. LISP programsare written as list expressions and so are easily manipulate by support programs written in LISP,such as EDITORS and programs that temporarily redefine functions or expressions in functions,which are useful when debugging. The presence of these types of features in LISP systems hasincreased the demand for them in other systems where they were not such a natural development.POP-2 was developed by AI researchers in the United Kingdom because there were no goodimplementations of LISP on the machines they were using because they disagreed with some of thefeatures of LISP and thought that others could be improved. It is still the most used AI language inthe United Kingdom but it has never been used much in the United States.

INTERLISP

The system that has gone furthest in the direction of including user facilities is INTERLISP[TEIT 1978], which evolved from a series of LISP systems at BBN, notably 940 LISP in 1967 andBBN LISP in 1970. As well as highly developed versions of the facilities described above, it hasthe following features: a uniform error-handling system that allows some types of automatic errorcorrection, such as spelling correction, entry to a special, flexible debugging facility, and handling ofparticular error conditions by user functions; CLISP - an alternative extensible expression syntax;PROGRAMMERS ASSISTANT - which keeps track of a user's commands (which are lists) and soallows selected commands to be undone, redone or edited, and redone; MASTERSCOPE - a cross-referencing facility that creates a database of a user's program and uses it to answer user queries;FILE PACKAGE - which keeps track of the state of a user's program, such as storing functions thathave been altered, on a permanent file at the end of a debugging and editing session. Thesefacilities have been written so as to enable the user to have a large amount of control over the waythey behave, made possible because the user can specify general LISP functions to be executed atimportant points of the system, as well as being able to set many global variables which helpdetermine the system's behavior.

In 1976 an implementation of Bobrow and Wegbreit's spaghetti stack [] was incorporated intoINTERLISP to provide convenient primitives for building very general control structures. [Seesection on Control Structures for further description].

The features that have been added to INTERLISP over the years give a strongdemonstration of how receptive the LISP framework is to the incorporation of new ideas unrelatedto the design considerations for LISP. One recent example of this is the introduction of an optionalpackage for including type declarations in programs. Characteristically for a LISP system feature,the user can use as much of this as his personal style and particular program require. Typechecking can be done when the program is running interpretively to aid in debugging, but need notbe included in the compiled version of the same program if efficiency is considered more importantthan caution. On the other hand the compiler may take advantage of type declarations to producemore efficient code. General addition of types is allowed in a hierarchical manner, with the power ofspecifying arbitrary LISP functions for such things as type checking, or what to do when assigningto a variable of a given type.

9AI Languages

MACLISP

MACLISP has been under continuous development since it was begun in about 1966 at MIT.MACLISP developed in parallel with INTERLISP. Fairly frequently, a feature in one that wasfound to be useful was implemented in the other. There has, however, been more of an emphasison efficiency in time and space utilization in MACLISP. Some of the main forces pushing in thisdirection were the increasing requirements of MACSYMA and, to a somewhat lesser extent, ofhigher level AI programming languages such as MICROPLANNER and CONNIVER, which wereimplemented in MACLISP. In contrast to INTERLISP, where most of the user facilities areresident in the system's core image, the user facilities in MACLISP are in separate programs or areautomatically loaded when required. This feature is acceptable because it has a fast loader and theoperating system has good facilities for skipping between one program, such as an editor, to another,such as MACLISP. The code produced by the MACLISP compiler is very efficient, on the order oftwice the efficiency of INTERLISP compiled code. In particular, effort was directed at producingefficient compiled arithmetic; and by 1974 this objective had been accomplished to such an extentthat compiled arithmetic was comparable to that of a FORTRAN compiler.

SAIL

In 1969 at Stanford, SAIL resulted from combining LEAP, an associative retrieval formalism,with a version of ALGOL 60. It was designed for those AI systems, such as vision and speechunderstanding systems, that required fast arithmetic and some of the facilities available in LISP.Some of the facilities that make SAIL convenient to use are its string-handling capabilities, a macrofacility, and convenient I/O. The associative database consists of attribute-object-value triples,which were used to do the same sort of things that LISP had done with properties of atoms.However, they are more powerful than LISP properties in that any of the keys can be used toretrieve values for the other slots. This and other features they shared with the PLANNER-likelanguages discussed in the next section.

Around 1973 some more facilities were added, prompted by other languages, especially LISP.A restricted type of list was introduced that did not allow lists as its elements. This deficiency wasovercome by the introduction of records. However, unlike LISP, routines for manipulating the listsand records and for performing I/O on them must be supplied by the user. Another facility addedwas a very powerful interactive debugging system: BAIL. General control structures, includingmultiple parallel processes, were also added.

POP-2

POP-2 is a language with many of the properties of LISP but with an ALGOL-like syntax.It was developed around 1971 by Popplestone, Burstall, and others at the University of Edinburgh.Like LISP it is interactive and allows general manipulation of functions. It was intended forefficient implementation on the medium-sized machines available to the authors. Thus, it relies onpackages that have to be explicitly loaded when required, to supply user facilities. It allows partiallyapplied functions to be created that can be used to do the same sort of things as FUNARGs. It alsohas dynamic lists, which are lists with a function at their end that is automatically called when morelist elements are required. This feature can be used to implement generators and allows such thingsas I/O devices to be treated as lists. The stack can be explicitly pushed and popped, which allowsfunctions to return multiple values fairly cleanly.

10AI Languages

3. Higher Level AI Languages

At the end of the 1960s and the beginning of the 19705, a number of languages weredeveloped that were designed to provide primitives useful for programs that require problem-solving and deduction facilities. An important idea behind them was that techniques that werethought to be generally useful should be generally available, so that new systems could be built moreeasily. <These languages differed in how much they imposed on the user and how much theyprovided flexible tools.>

PLANNER

PLANNER was designed by Hewitt from about 1967 to 1971 as a foundation for problem-solving [HEWI 1971]. It was built around the idea that the essential thing about knowledge washow it was used in achieving purposes. Hewitt tried to develop a formalism whereby any piece ofknowledge could be naturally expressible in a procedure that would use it where appropriate. Thisapproach was partly in reaction to the uniform proof procedures that were then widely used, wheredomain knowledge is represented as propositions that are manipulated by a domain independenttheorem prover to produce the desired result []. Some of the ideas introduced by Hewitt are asfollows. Goal-directed invocation of procedures, whereby each procedure has a pattern thatrepresents the goals that it can achieve, so that it can be called whenever it is relevant to achieving adesired goal. He emphasized the importance of backtrack control, whereby choices can be made andtheir implications explored, while still maintaining the capability to reject these choices together withall their consequences, in order to try other choices based on the reasons for rejection [see article oncontrol structures for further description of backtracking]. Rather than having an explicit goal tree,as in previous problem-solving systems such as STRIPS [] or GPS [], the goal tree is implicit in thecontrol structure of the program.

Only a portion of PLANNER was actually implemented as MICRO-PLANNER in 1972 [j.It included pattern-directed invocation of procedures and automatic backtracking. Each procedure isindexed in an associative database by a pattern indicating what it is useful for. There are two typesof procedures: consequent theorems and antecedent theorems. A consequent theorem is called when itspattern matches a subgoal to be solved. An antecedent theorem is called when its pattern matchesan assertion added to the database (there is another kind of antecedent theorem for assertionsdeleted from the database). Antecedent theorems can be used for forward reasoning and for keepingthe database consistent. Another use is for setting up expectations. For example, suppose that it isimportant when one assertion added to the database is followed by the addition of a certain otherassertion to the database. This can be checked by having the first assertion trigger an antecedenttheorem that sets up an antecedent theorem to be triggered if the second assertion is, in fact, added.The reason for calling them theorems comes from analogy with the way that theorems were used(and are stil used) in AI inference systems. Thus, a theorem of the form "A = B" is used in twoways: if it is desired to show "B" then this theorem allows you to set up the subproblem of proving"A", which if true will allow you to conclude "B" is true also; alternatively, if you find that "A" istrue the theorem allows you to conclude that "B" is true.

<systems that used it - SHRDLU, Charniak's>

AI Languages 11

CONNIVER

CONNIVER resulted from a reaction by Sussman and McDermott to what they consideredexcesses in MICRO-PLANNER [SUSS 1972, MCDE 1974]. It retained many of the ideas ofPLANNER, but at a lower level so that fewer of the mechanisms were imposed on the user. Inparticular, Sussman and McDermott objected to the use of automatic backtracking. In MICRO-PLANNER, most of the information gained from following a wrong choice was lost on failure. Theresult was that programs tended to get bogged down in blind back-tracking.

CONNIVER introduced the idea of a tree of contexts in the database. This tree was used torepresent the different situations for different choices of actions at the same time. A powerfulpattern matcher was implemented that allowed flexible associative access to the database. A versionof the spaghetti stack was also implemented, using lists rather than a stack, so it was ratherinefficient. Together, the spaghetti stack and context tree allow, for example, a problem-solver tosuspend a process working on one subproblem and to continue work on another subproblem thatseems more promising, and then, at some later point, to resume the process working on the originalsubproblem if necessary.

<systems that used it - HACKER, BUILD>

QA4 and QLISPQA4 was developed by Rulifson and others[] around the same time as MICROPLANNER.

It was preceded and influenced by QAI, QA2 and QA3, which were all developed by CordellGreen. QA I was an attempt at formalizing the ideas In Raphael's SIR program, that Raphael hadseen to be too ad hoc and as a result difficult to extend. Before this was completed it was seen byRaphael and Green that the ideas of resolution theorem proving were suitable for the task. This ledto the development of the resolution theorem based system of QA2. QA2 introduced the nowstandard method for extracting answers from the process of proving theorems with existentiallyquantified variables - i.e. values for the variables which satisfy the theorem. QA3 was an improvedimplementation of QA2 in which Green explored how to tackle various types of problem using aresolution theorem prover [], including program synthesis, verification, and problem-solving. QA3was also used in STRIPS [] and ZORBA [].

QA4 was intended to overcome certain problems found in using QA3 - specifically thedifficulties of guiding search. It was difficult to specify procedural and domain dependent knowledgein a way that the theorem prover could use. It was seen to be useful to have theorems or proceduresindexed by their purpose, an idea which led to the implementation of pattern directed invocationsimilar to that of PLANNER. QA4 was the first language to develop the idea of representingassertions uniquely, in the way that atoms are represented uniquely, so that properties can beassociated with assertions. It used a context mechanism like that of CONNIVER and also had ageneral control structure. To make it more widely available and to take advantage of new facilitiesin INTERLISP, a cleaner implementation was embedded in INTERLISP and called QLISP. Whenthe spaghetti stack was implemented in INTERLISP, QLISP was modified to take advantage of it.Unlike MICRO-PLANNER and CONNIVER, which are interpreted languages on top of LISP,QLISP is basically a subroutine package for INTERLISP. This makes it much easier to mixQLISP with INTERLISP.

Additional features of QLISP are extra data types like sets, tuples, and bags, together withprocedures for handling them, and the ability to use them in pattern matching. Pattern matching

12AI Languages

plays a larger role in QLISP than in CONNIVER, being used for such things as constructing data.QLISP also makes the distinction, blurred in PLANNER, between finding the truth of an assertionby doing a simple look-up in the database and finding it by deduction using consequent procedures(PLANNER theorems). Everywhere that a pattern-directed procedure call may occur, QLISP allowsthe user program to specify a team of procedures that should be considered. A team consisting of asingle procedure corresponds to the traditional style of programming, whereby a "subproblem" issolved by calling a specific function. On the other extreme, a team consisting of all the goal-achieving procedures corresponds to the nondeterministic style of PLANNER, whereby thesubproblem is announced and any procedure whose purpose matches the subproblem descriptionmay be called.

<systems that used it - NOAH, Waldinger's verifier>

POPLER

Developed by Davies in 1973 at the University of Edinburgh, POPLER is a language basedon PLANNER and embedded in POP-2. It has an implementation of the spaghetti stack. It makesthe same distinction as QLISP between testing the database and calling consequent procedures, andit further distinguishes between those procedures that deduce the value of an assertion in a worldmodel from those that achieve the assertion as a goal, producing a new world model from the oldmodel.

<systems that used it - >

<thls section on POPLER needs more information. Perhaps it should be deleted and justhave a short note under PLANNER?>

13AI Languages

4. Conclusions

The higher level AI languages have had an important influence on AI. The most strikingthing about them, though, is that none are being used much now. Most were used to write a fewimportant systems that demonstrated the utility of the featuoundembedded in the system, andsometimes the limitations of the system, and then were not used again. Now most of the programs ofthe type that were written in these languages are written in LISP. Frequently, however, some of thefeatures of the higher level AI languages, such as the associative database or backtracking, areimplemented in the new programs, although in a form specialized for the particular task.

There are two main reasons for this disuse of higher level languages. First is the problem oftime and space efficiency. Second, the concepts built into the languages have not coincided closelyenough with those that researchers later wanted for AI programs. Although researchers typicallywant to use some of the features of the AI languages, they may not want to pay the price of havingall the unwanted features around; and the modularity of the systems is not sufficiently good to allowthe extraction of the desired features (which has also been a criticism of INTERLISP). If what iswanted is not quite what is provided, then the user may have to struggle with the system to get whathe wants. It has been quite difficult for an embedded system such as MICROPLANNER orCONNIVER (QLISP is not embedded but is a set of functions callable from INTERLISP) tocommunicate cleanly with the host language, mainly because the control and variable stacks are notshared. Also, for a specific task, there is often a more efficient way of implementing a feature thanthe fairly general method used in the programming language. Occasionally a commonly used featurehas been implemented in a lower level language, such as in the case of the spaghetti stack inINTERLISP.

This situation has resulted in some wasteful duplication of work. Such waste might beavoided in the future by having more packages with smaller scope and with fairly specializedapplication. Then a program builder could select those required. Another possibility is that someintermediate level language might be designed that allows higher level constructs to be defined easily.

Some Current Directions

<The following section is a bit rough. What else should be mentioned? >

A number of programming languages for AI have been developed since those describedabove. None of these have had widespread use and it is too early to know their significance. Threecategories are considered:- new LISP dialects, languages based on logic, and knowledgerepresentation languages. <also mention FUZZYx

A number of LISP machines are being developed using dialects similar to current dialectssuch as MACLISP and INTERLISP. Different machines are being developed at M.I.T. AILaboratory [], BBN [], and Xerox PARC <NO REF?>. The standard use of lexical binding ratherthan the usual dynamic binding for LISP has been proposed and implemented in SCHEME, avariant of MACLISP [STEE 197?]. Steele and Sussman argue that lexical binding is more naturalfor commonly used AI control structures such as coroutines and generators, and that the fullgenerality of the spaghetti stack is not necessary for AI applications. The latter is supported by thefact that AI systems have not so far taken much advantage of the full generality offered by thespaghetti stack. A major new LISP implementation, NIL, for new large address space machines usesSCHEME as a model, in particular, its lexical binding.

14AI Languages

Two languages based on first order predicate calculus are PROLOG [] and FOL [].PROLOG programs consist of "axioms" in first order logic in horn clause form, together with atheorem to be proved. If the theorem contains existentially quantified variables the system willreturn instantiations of these which make the theorem true (if such exist) using methods based onthose of QA3 []. The style of programming is similar to that demonstrated in QA3 and, to a lesserextent, PLANNER. Automatic backtracking is used but the programmer may add annotation tocontrol which order clauses and axioms are considered. A compiler has been implemented forPROLOG that enables programs in a variety of domains to execute in terms of time comparably tocorresponding compiled LISP programs. Another direction of logic has been explored throughFOL: the uses of meta-theory. FOL is primarily a proof checker that accepts logic statements andproof step commands that can be carried out and tested for correctness. However, it provides apowerful theory manipulating structure that allows the building of arbitrary meta-theory. Thus, forexample, a theorem may be proved not only within a theory but also with the help of the meta-theory. Proving a theorem by going through the meta-theory corresponds closely with executing aprocedure to produce the theorem.

The representation languages have been based on the idea of frames discussed in theRepresentation Chapter []. These include KRL and FRL, which are built on top of LISP. Theselanguages provide frame data structures and procedures for manipulating them, including patternmatchers. Procedures can be attached to slots in the frames to be called in particular circumstancesinvolving the slot, such as when the slot is filled, changed or examined. The languages do notprovide a separate language for specifying procedures; the host language being used for this.

REFERENCES

Bobrow, D. O, "Requirements for Advanced Programming Languages for ListProcessing Applications", Communications of the ACM, July, 1972, pp. 618-627.

Bobrow, D. G. and Raphael, 8., "New Programming Languages for Artificial IntelligenceResearch", ACM Computing Surveys, September, 1974, pp. 153-174.

Bobrow, Daniel O, and Raphael, Bertram. "A Comparison of List-Processing ComputerLanguages," Programming Systems and Languages, cd. Saul Rosen. New York: McGraw-Hill, Inc.,1967.

Daniel G. Bobrow and Bertram Raphael. A Comparison of List-Processing ComputerLanguages, CACM, 7:4, April, 1964, 231-240.

D. G. Bobrow and B. Wegbreit, "A Model and Stack Implementation of MultipleEnvironments", CACM, Vol. 16, No. 10, pp.lo-39, October, 1973.

Burstall, R.M., et al, Programming in POP-2, Edinburgh University Press, Edinburgh, 1971.Contains a primer and the POP-2 reference manual.

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

Feldman, J.A. and Rovner, P.D. An ALGOL-based Associative Language. CACM, 1969,12:8, 439-449.

<incomplete>

15AI Languages

C. Hewitt, "Description and Theoretical Analysis (using schemas) of PLANNER: A Languagefor Proving Theorems and Manipulating Models in a Robot", Phd Thesis, MIT.Feb., 1971.

C. Hewitt, "Procedural Embedding of Knowledge in PLANNER", 2nd IJCAI, 1971.

McCarthy "History of LISP" (unpub.)

McCarthy "Recursive Functions of Symbolic Expressions and their Computation by Machine"

D. V. McDermott and G. J. Sussman, "The Conniver Reference Manual", MIT AI Memo No.259A, January 1974.

Popplestone, R.J. "The design philosophy of POP-2", in Machine Intelligence 3, pp. 393-402,D. Michie, cd. Edinburgh University Press, 1968.

Pratt "LISP: An Amicus Curiae Brief"

R.Reboh, E. Sacerdoti, "A Preliminary QLISP Manual" Stanford Research Institute AI Tech.Note 81, 1973

Reiser, J. Sail Users Manual, Stanford A. I. Memo AIM 249. Stanford, Calif.: SAILStanford University, 1976.

Sandewall, E. "Programming in an Interactive Environment: the LISP Experience", ACMComputing Surveys

Smith, R.L. TENEX SAIL, (Technical Report No. 248) Stanford, Calif.: IMSSS, StanfordUniversity, 1975.

Smith, Douglas K. "An Introduction to the List-Processing Language SLIP," ProgrammingSystems and Languages, cd. Saul Rosen. New York: McGraw-Hill, Inc., 1967.

G. J. Sussman, T. Winograd, and E. Charniak, "MICRO-PLANNER Reference Manual",MIT AI Memo 203A, DEcember, 1971.

G. J. Sussman and D. V. McDermott, "Why Conniving Is Better Than Planning", MIT AIMemo No. 255A, April 1972.

W. Teitelman, "INTERLISP Reference Manual", Xerox Palo Alto Research CenterDecember, 1975

W. Teitelman, "Toward A Programming Laboratory", Proceedings IJCAI3, StanfordCalifornia, August, 1973, pp.l-Ba.

Weizenbaum, J. "Symmetric List Processor," Communications of the ACM, VI (September,1963).

White, J.L., "A Historical Perspective on MACLISP