AI APPRENTICE
EXPLORE EXPERT SYSTEMS WITH XLISP
by Christopher F. Chabris
An
introduction to Artificial Intelligence- its languages and its methods-including
an examination of LISP and a working expert systems program written in
XLISP. Look in the folder XADVISOR.STQ on your START disk.
Artificial intelligence has at last arrived for the Atari community. With the 16-bit ST line, Atari has provided a computer whose capabilities approach those of advanced systems used for university and industrial research. At a fraction of the price, Atari enthusiasts now have the power to experiment seriously with artificial intelligence in languages like LISP and PROLOG.
WHAT IS ARTIFICIAL INTELLIGENCE?
As an idea, artificial intelligence (AI) provokes both fear and philosophical controversy. Many enthusiasts possess an almost religious faith in AI, while others violently resist the very notion that a machine can be made to think like a human being. But though they will dispute its ultimate feasibility, defenders and detractors alike usually agree that AI as a science is mysterious, fascinating, and often misunderstood.
Assuming AI is at least theoretically possible, what exactly do we mean by artificial intelligence? We could discuss this endlessly but I propose, as a working definition, that AI is a science composed of three closely related areas of investigation:
- ROBOTICS: By this I do not mean the study of industrial robots, mechanical arms, etc., hut a general research program whose ultimate goal is the construction by whatever means are necessary of a complete and artificial simulation of a human being. Many AI opponents have criticized this goal of AI because it has serious philosophical and social implications. It is still far from being achieved after 30 years of research.
- COGNITIVE SCIENCE: This is the study of cognition, or the processes, structures, and mechanisms of human thought. Many psychologists working in this area use computer models to help them learn more about the brain.
- APPLICATIONS: Making computers more useful to people by applying the theories and techniques of AI. We will concern ourselves primarily with this engineering side of the discipline, writing experimental programs in AI languages.
PRACTICAL APPLICATIONS
Applied AI research concentrates on several different areas, most notably the following:
- NATURAL LANGUAGE PROCESSING: Programming computers to understand "natural" languages such as English is important for database management and query. Rudimentary front-end programs for microcomputer databases can translate requests such as "Show me last month's national sales figures broken down by region and product into the system's query language. Another system under development reads newspapers and composes summaries of their content.
- COMPUTER VISION: Much research is concentrated on vision, an important capability for robots and optical scanners. Very simple programs can be constructed to identify shapes in three-dimensional scenes, compare and match objects, and so on.
- MACHINE LEARNING: The ability of the computer to learn, to acquire new skills and knowledge, may he the "missing link" in Al. Much of the work in learning is exciting and relatively recent, but practical applications have yet to be investigated extensively.
- GAME PLAYING: Chess computers represent a significant achievement of Al research. The best program today is stronger than 99 percent of human players and continues to improve. In backgammon, a computer had already defeated the world champion by the late 1970s.
- SYMBOLIC MATHEMATICS: Machines have always been good at numeric calculations, attaining blazing speeds multiplying, dividing, etc. But in the 1960's AI researchers began to program for symbolic operations, such as differentiation and integration of functions. MACSYMA, a popular expert systems program, was the eventual outgrowth of that early work, and is now used widely by engineers for most of these operations.
- EXPERT SYSTEMS: The most successful and visible outgrowth of AI research, expert systems are programs which mimic the reasoning process of a human expert when attempting to solve a particular class of problems. Expert systems are currently used in a wide variety of applications including law, medicine, electronics, chemistry, geology, finance, and the like. Later, we will explore expert systems in detail and build a simple expert-systems program. But first, we need the tools with which to build it.
enthusiasts now
have the power to
experiment seriously
with artificial
intelligence.
AI PROGRAMMING LANGUAGES
Most AI programming is done in specialized languages-not C, Pascal, or assembler (heaven forbid), the languages normally used to develop ST applications-but usually either LISP or PROLOG.
LISP is an acronym for LISt Processing because its primary data structure is the list. It was invented by John McCarthy the man who coined the phrase "artificial intelligence" in the late 1950's. It is one of the oldest programming languages, and today's main dialect, Common LISP, bears a close resemblance to the early versions. Nevertheless, LISP is still a modern language that is used for at least 90 percent of all AI research programming.
There are several reasons for this popularity. One is that LISP is well-suited for symbol manipulation, as we shall see later. Another is that LISP programs can be both interpreted and compiled. The former allows easy modification and experimentation, desirable in a research setting, while the latter provides the execution speed necessary for a commercial product. Finally LISP has proved worthy as a general-purpose programming language. Word processors-even entire operating systems have been constructed in LISP, and its use is spreading to other applications.
PROLOG, which stands for PROgramming in LOGic, is a language that was developed in France around 1970 by Alain Colmerauer and his colleagues. A declarative language, it was a first attempt to realize the ideal of logic programming. Rather than explicitly state which steps the computer is to perform, and in what order they are to be executed (imperative or procedural programming), the programmer declares in logical form the relationships and facts of the algorithms and data, and lets the computer take care of the control. At first this is a difficult structure to grasp, being foreign to most programmers. But PROLOG is quite powerful if used correctly and has been chosen by the Japanese for their vaunted Fifth Generation project.
An important trait shared by LISP and PROLOG is their homogeneity Programs and data have the same structure, and it is a simple matter for programs to create new procedures or modify themselves during their execution. Try doing that with C or Pascal!
EXPERT SYSTEMS
One of the first scientists to recognize the commercial potential of artificial intelligence was Edward Feigenbaum of Stanford University. He is generally credited with inventing the expert system, a type of AI program that is supposed to be able to solve difficult problems the same way a human expert would: by bringing a large body of explicit knowledge to bear on the situation at hand and somehow using it to deduce a solution.
An expert system normally consists of four parts: a knowledge base,
the encoding of the knowledge necessary to solve the problems for which
the system is designed; the inference engine, the software that draws conclusions
from the knowledge and the facts of the case; one or more databases of
relevant facts; and some sort of user interface. We could define an expert
system as a program that is expert in some area, but then we could consider
a calculator desk accessory an expert system in the domain of arithmetic.
While this is certainly not untrue (can you multiply faster than your computer?),
it trivializes the class of problems for which expert systems are designed:
domains without unified theories but rather large bodies of disorganized
knowledge that experts must draw upon to make decisions.
ability of the
computer to learn
may be the
"missing link"
in AI.
Most expert systems in use today are rule-based. Their knowledge is represented as a collection of heuristic rules that specify precisely what conclusions can be made under which circumstances, and sometimes with approximately what certainty of correctness. Such production rules usually take on a relatively simple IF-THEN form like these examples from well-known expert systems:
IF: the gram stain of the organism is negative, the morphology (shape) is rod, the aerobicity is anaerobic, THEN: the organism is bacteroides. IF: the context is layout and assigning a power supply, an sbi module of any type has been put in a cabinet, the position it occupies in the cabinet is known, there is space available in the cabinet for a power supply, there is an available power supply, THEN: put the power supply in the cabinet in the available space.
The first example comes from MYCIN, a pioneering medical diagnosis system developed at Stanford over the last fifteen years. The second is from XCON (formerly R1), a program in daily use at the Digital Equipment Corporation to configure VAX computer orders. The two rules share a common structure that looks like this:
IF: <antecedent condition 1>
(AND)
<:antecedent condition 2>
(AND)
<antecedent condition n>
THEN: <consequent action(s)>
(are all performed)
Normally each condition can take on a truth value of either TRUE or FALSE. A condition is presumed FALSE until proven TRUE; this is known as the closed-world assumption. The classical rule of inference used to make deductions with these rules is called Modus Ponens, and it states the apparently obvious:
Given a rule: A implies B,
and given: A (is true),
we conclude: B (is true).
In our case, this means that if all the antecedent conditions are TRUE, then the consequent actions are performed. These could be simply assignments of truth values to other facts, or maybe entire procedures to be executed (in LISP, expressions to be evaluated).
Note that a rule itself is context-independent; that is, the quantum of knowledge it embodies is always applicable within the domain of the expertise. The XCON rule above uses the first few antecedents as a guard to establish the situations in which it is applicable, but as a whole the rule is context-independent. If we try to use it in the wrong context, it will just fail with no undesirable side effects, and we can go on to the next one.
Notice that these production rules are a declarative form of knowledge representation, akin to the logic programming concept introduced earlier in the discussion of PROLOG. The rules say absolutely nothing about how or when they will be executed: all the control information comes from the inference engine itself, which decides especially the order in which to use the rules. The rules could have associated "priority" values, for instance, but it would nevertheless be up to the inference engine to refer to those values for guidance.
The program we will examine is XADVISOR.LSP on your START disk. XADVISOR is a production system interpreter (a generic inference engine) written in XLISP that embodies some of the principles introduced above. You may be surprised to see that the entire program, including comments, is just 160 lines long! This includes the inference engine and the user interface, but not the knowledge base. The program will work with any knowledge base in any domain whatsoever as long as its format is syntactically acceptable (as will be described later).
ADVANCED CAPABILITIES
There are several capabilities common in real-world expert systems that are missing from XADVISOR, including the following:
- CERTAINTY FACTORS: In diagnosis, we can rarely be completely certain of our results; rather, we have degrees of confidence in the correctness of our reasoning. Some expert systems use statistical tools like "Bayes' Theorem" to calculate the certainty of deductions based on the certainties of the antecedents being true and the certainties of individual rules being applicable. In this way, they can offer a range of diagnoses with the approximate probabilities that each is correct, along with prescribed treatments that take this information into account.
- EXPLANATION FACILITIES: Good expert systems should be able to not only make deductions, but also to explain how they were made. Whenever the user is asked to provide more data to the program, he should be able to ask why he is being asked the question so that he can follow the system's execution and understand how it arrives at its conclusions. Indeed, many say that an expert system is not truly "expert" if it does not know how it makes its decisions.
- METALEVEL REASONING: lt is possible to add control strategy to the system's knowledge via "metarules," or rules about the rules. This is becoming increasingly necessary for the needs of large systems for reasons of efficiency With thousands of rules to choose from, what guarantees an uninformed inference engine will select those rules that are most applicable to the current context (the facts in the database)? Wandering about aimlessly without outside guidance, it could waste valuable time pursuing dead-end reasoning paths.
- LEARNING/KNOWLEDGE ACQUISITION: Expert systems can be costly to maintain and update, so researchers have sought to solve the problem of machine learning within the domain of expert systems. The user should be able to interactively interrogate the knowledge base, and, with the program's assistance, modify its rules to correct bugs or add new information. Randy Davis's TEIRESIAS addition to MYCIN enabled a physician to easily use and update the system unattended.
- REFINED USER INTERFACE: XADVISOR's interaction with the user is limited to yes/no questions, whereas the state-of-the-art systems in use today can carry on natural-language dialogs and allow for graphical input of various data. This issue really has as much to do with software engineering as with expert systems themselves.
There are two basic methods an inference engine can use to operate on the knowledge and make deductions; goal-oriented backward chaining and data-driven forward chaining. In the former procedure, the system attempts to establish the truth value of a goal fact with respect to the given data, while in the latter it takes that data and makes all possible deductions until it has proven one, several, or all goal facts.
Backward chaining would be used if we had a goal in mind that we wanted to prove. We would use forward chaining if we had some data but no idea what result it might lead to, or if we wanted to find all possible conclusions reachable from the data. Note that these two control methods will never produce mutually inconsistent results: the set of facts deducible from the data with a set of (context-independent) rules does not depend on the order in which those rules are used. Both strategies are implemented in XADVISOR.
PROGRAM DESCRIPTION
We are at last ready to examine XADVISOR in depth. The XADVISOR sidebar and Disk Instruction page contain startup descriptions. (Editor's note: Thanks to David Betz, author of XLISP, and an effective data compression program from Quack Computer Company, we have found room on the START disk for a complete version of XLISP (v. 1.5b)from which you can run XADVISOR. Interested readers should obtain the complete XLISP package with documentation and source code from the sources listed in the sidebar. The remainder of this article is an analysis of the XADVISOR code and assumes some knowledge of LISP. We realize few readers will know this language and recommend they pick up any of the LISP books listed in the Reference section. We have found XLISP to work with most of the example code found in standard LISP books.)
Looking at the XADVISOR code, we find that the listing can be divided into four parts: the top level and initialization functions (ADVISE, PREPARE, IF), the backward chaining module (BACKWARDS, TRY-ALL, BACKWARDS-AUX), the forward chaining module (FORWARDS), and the utility functions used by them (ASSERT CONDITIONS, ASK-USER, TRUE, TERMINAL). The entire program amounts to these twelve definitions. Before we look at them, let's examine the main global variables used by the inference engine:
RULEBASE is the knowledge base of the system. It is a list of the production rules in the order that they were read from disk. Each rule is represented itself as a list whose CAR is a list of the antecedent conditions and whose CADR is a single consequent action. Individual conditions and actions (facts) are represented as lists, each containing one string literal.
PROVEN and DISPROVEN are the database of the system. They are simply lists that contain facts that have established truth values.
Now, on to the program's functions:
ADVISE is a front-end function used to query the program on a knowledge base that has already been loaded into memory. Its formal parameter list contains the keyword &REST, which binds the next atom to a list containing all of the remaining arguments to the function. Here, we use this to allow the user to pass one or more option descriptors, which are collected in OPTIONS for later use. Currently only INTERACTIVE is supported, but others could be added without changing the form of the ADVISE call.
Next we have a SETQ with more than two arguments; it simply binds each atom to the succeding value. Initially we use I-FLAG to indicate whether the interactive option has been selected, we set the list of PROVEN facts to the CONTEXT passed by the user, and we set the list of DISPROVEN facts to be NIL.
The rest of the function is just a COND expression that branches off to either the backward or forward chaining mechanism depending on the arguments to ADVISE. If there was no goal specified but the user did pass a list of known facts, he or she must want to forward chain from those facts. If there was no goal and no context, he or she must want to find the best solution given data that will later be entered interactively. If there was a goal, he or she must want to backward chain from it.
The rest of ADVISE just sets up some nice looking output. PRINC and TERPRI are standard functions that print out objects and issue carriage returns. The only other form here that we haven't seen before is LET. Without going into detail on its syntax, I can say that LET is a powerful construct that sets up local environments, or temporary bindings that only apply within the LET expression and disappear once it is exited.
PREPARE must be called by the user before the first call to advise ADVISE. Given a valid GEMDOS pathname, enclosed in double quotation marks, PREPARE passes it on to LOAD to read in the knowledge base from a disk file. For our purposes, please accept the actions of both PREPARE and IF (another special construct known as a macro) as magic. They are rather kludgey anyhow, and you can probably figure them out with the help of a LISP book.
BACKWARDS is the real meat of the program. This function takes any fact, presumably a consequent action in one or more rules of the knowledge base, and attempts to prove its truth. It does this in several ways. First, if ACTION is bound to NIL, it calls TRY-ALL (see below). If ACTION has already been proven, we return T. If it has been disproven, we return NIL. Otherwise, we bind CONDITION-SETS to a list containing all the sets of conditions that would satisfy the ACTION. If there are none, meaning there are no rules that mention the ACTION as a consequent action, we try to ask the user whether it is true or not. This is the only place where user interaction occurs, and it only happens if the user explicitly requested it in the call to ADVISE. (If the user felt he had provided all the facts in the CONTEXT variable, he could operate in a sort of "batch mode," just waiting for the system's advice.) On the other hand, if there are conditions on the ACTION, we call BACKWARDS-AUX to deal with them.
TRY-ALL, given a list of RULES-LEFT (to try), will try to backward chain from every 'terminal" goal, that is, every goal that is mentioned as a consequent action in one or more rules in the knowledge base, until it succeeds in proving one of them. It will then return that action, but it will return an inconclusive message if it still fails after recursing through the entire RULEBASE list.
BACKWARDS-AUX, given an ACTION and a list of the set's antecedents of rules that mention it as the consequent, will recurse through that list attempting to find a set of conditions that can be satisfied by ASSERT. If a call to ASSERT returns non-NIL, we can add the ACTION to the set of PROVEN facts and return T. Otherwise, if we run out of CONDITION-SETS, we return NIL as we are unable to establish the truth of the ACTION.
FORWARDS is a huge function that forward chains from the facts contained in PROVEN to deduce more facts, eventually either deducing goals or running out of things to deduce. When called from ADVISE, it is initially passed the rulebase reversed (using the built-in function REVERSE) so that the lowest priority rules appear first. It operates by recursing through the rules in this order, attempting to find rules whose consequent actions are not already proven but whose antecedent conditions all are. When this happens, it has deduced a new fact, so it adds that action to the PROVEN list and begins again at the end of the rulebase. When it deduces a goal, it adds it to the list ANSWER-STREAM which will contain all the goals deduced from the given set of PROVEN facts. If it ever runs through the entire rulebase without a single rule firing, then clearly nothing more can be deduced. In this case, if ANSWER-STREAM is non-empty we return it, otherwise we return the inconclusive message.
By now I hope you have noticed that, despite all the parentheses and the convention against comments embedded within functions, LISP programs are relatively easy to read. This is due to LISP's modular structure, long symbolic atom print names, and the self-documenting nature of its function names.
The remaining five functions of XADVISOR offer good examples of recursive list manipulation and I/O. In ASK-USER we print a question about the truth value of a particular ACTION and then call on built-in function READ to obtain the answer. READ is actually the same reader we met early on at the beginning of LISP's top level READ-EVAL-PRINT loop. As shown here, it can be called any time, and will return a symbolic expression obtained from standard input. Of course, EVAL and PRINT are also available to user programs, though they were not directly necessary to this one.
In fact, in my experience, XADVISOR is an excellent example of how much can be accomplished with a very few LISP primitives. We didn't use any fancy object-oriented programming techniques, destructive list modification, anonymous functions, property lists, or other esoteric powerful features of the language. XADVISOR was originally written in Franz LISP, a dialect that runs primarily under the UNIX 4.2BSD operating system on VAX minicomputers. It required changes to only eight lines of the source code to port it over to XLISP running under TOS on the Atari ST.
To help you get started experimenting with XADVISOR and XLISP, I have included two sample knowledge bases on the disk: HIRING.RUL and CHESS.RUL. The former, containing 15 rules, makes a somewhat whimsical attempt to advise a Computer Science department chairman on hiring candidates for faculty positions. The latter, with 57 rules for recommending plans in chess positions, taxes the abilities of a limited production rule interpreter like XADVISOR. With some easy extensions and major additions, XADVISOR could be suited to such a complex problem domain.
CONCLUDING THOUGHTS
I hope this article has raised your interest in artificial intelligence, expert systems, and LISP programming. We had a lot of ground to cover, but you can catch up and learn far more by reading any of the books listed below. With the ST, you have a machine that is definitely capable of serious AI work. One company is marketing the Macintosh as an AI workstation for LISP and expert systems, so why not the faster, higher-resolution ST?
The most difficult tasks for human beings, such as multiplying ten-digit numbers or remembering detailed facts, are simple even for tiny computers. But the simplest second-nature human behavior, such as reading, speech, and vision, is extremely difficult for today's most powerful computers. These differences-between the machine and the mind - make the challenge of artificial intelligence all the more intriguing.!
REFERENCE:
For an entertaining introduction to artificial intelligence, very suitable for the non-technical reader:
- The Cognitive Computer: On Language, Learning, and Artficial Intelligence, by R.C Schank with P Childers, Addison-Wesley Reading, MA
- Introduction to Artificial Intelligence, by E. Charniak and D. McDermott, Addison-Wesley, Reading, MA
- Artificial Intelligence (second edition), by PH. Winston, Addison-Wesley Reading, MA
- Building Expert Systems, by F Hayes-Roth, D.B. Lenat, and DA. Waterman, Addison-Wesley Reading, MA
- Introduction to Expert Systems, by P Jackson, Addison-Wesley Reading, MA
- A Guide to Expert Systems, by 0. Waterman, Addison-Wesley Reading, MA
- Artificial Intelligence Programming, by E. Charniak, C. Riesbeck, and D. McDermott, Lawrence Erlbaum Associates, Hillsdale, NJ
- Common LISP: The Language, by G.L. Steele, Digital Press, Burlington, MA
- LISPcraft, by R. Wilensky WW. Norton, New York, NY
- LISP (second edition), by PH. Winston and B.K.P Horn, Addison-Wesley Reading, MA
- Programming in Prolog (second edition), by W.E Clocksin and CS. Mellish, Springer-Verlag, Berlin, Germany
- Introduction to Logic Programming, by CJ. Hogger, Academic Press, London
- Prolog for Programmers, by F Kluzniak and S. Szpakowicz, with J.S. Bien, Academic Press, London, England
HOW
TO USE
XADVISOR
The files you'll need can be found on your START disk in the folder labelled XADV1SOR.STQ. Copy them to a new disk before using or modifying them. A complete version of XLISP (v. 1.5b) has also been included on your START disk. Please note: We have had to compress XLISP in order to fit it on the disk. You must unsqueeze" the XLISP program before it can be used. See the Disk Instruction page for further instructions on this. Interested readers should obtain the XLISP documentation and source code. There are at least three possible sources:
- User groups. Many have a version of XLISP in their public-domain libraries or on their Bulletin Board Systems.
- CompuServe. Check Data Library 3 (Utilities) of the ATARI16 Forum. To speed your search, use the keyword XLISP" (what else?). The version posted here (v. 1.5b) is the same used during the development of XADVISOR and this article.
- The Catalog. An XLISP disk has recently been added to the ST Public Domain section.
1 If you received an INIT. LSP with your copy of the XLISP interpreter, replace it with the version on the START disk. It ensures that enough memory is allocated for the XADVISOR program and performs several other useful services for you.
2 Make sure that both INIT.LSP and PPRINT.LSP are in the same directory as the XLISP program. Install XLISP as a TOS-takes parameters' application on the GEM Desktop. If you like, give it a document type of LSP (It is a good idea to give all your LISP files this extender. for this and other reasons we shall see later)
3 Locate XLISP and double-click on its icon. A dialog box will open, prompting you for parameters. You can enter as many filenames as you wish, hut he sure to leave off the .LSP extender; XLISP will add it to whatever you type. If you don't want to load any files right away, just press [Return].
4 The XLISP interpreter will load and run. First, the message "XLISP version 1.5b Copyright (c) 1985. by David Betz" will appear at the top of the screen. Second, XLISP will try to open the file INlT.ISP and evaluate all the expressions it contains. Afterwards, or if INIT.LSP cannot he found in the default directory, XLISP will similarly load the files you specified as parameters in the order in which you listed them. Finally, it will enter the top level READ EVALPRINT loop, issuing a cryptic ">" prompt.
5 At this point, if you did not specify
XADVISOR" as a parameter in the dialog box, type the following:
(load "xadvisor.lsp")
and press [Return], Note that here, with the load function,
you must specify the extender in the filename.
6 Once the XADVISOR.LSP file has been loaded successfully, you are ready to consult a knowledge base. Two are supplied on the START disk: HIRING.RUL and CHESS.RUL. For demonstration purposes we'l1 use the former because it is smaller, but the procedures are the same no matter which knowledge base you use. (I recommend a .RUL extender on all your knowledge bases for mnemonic purposes.
7 At the next ">" prompt, type (prepare "hiring.rul") and press [Return]. This will cause the knowledge base about hiring faculty to be loaded and prepared for consultation. (Note: If you receive an error message from mistyping and end up on a numbered prompt- such as 1:> press Control-G until you reach the top-level ">" prompt.)
8 We are ready to ask XADVISOR for advice!
Try entering the following for starters (at the prompt):
(advise nil nil 'interactive)
The program will start to ask you questions like this:
Is is true that:
(candidate is one of the top ten in his or her field)?>
Make up some answers (either Yes or No) and see how the
program responds. Eventually, you will either receive a suggestion like
this:
I advise offering the candidate a senior faculty position.
OK
Or, perhaps this message:
I cannot give any advice based on the given context.
OK
The former represents the best possible advice the program could give
based on your answers to the questions. The latter means that the program
couldn't draw any meaningful conclusions from your answers.
9 The above method is the easiest way to query XADVISOR, and the only one needed. It is possible, however. to start the program with a list of already known facts, so that you don't waste time answering them, or a "goal" fact-one towards which the system should orient its deduction. The first nil in the above command represents the "known facts" parameter. and the second nil the goal. A glance at the HIRING.RUL listing will show examples of both statements. Newcomers to LISP will have difficulty establishing the proper sequence of parentheses and quotes necessary to properly input the parameters, but here is an example of how to input a goal parameter: First, setq the list to a label, such as "junior":
(setq junior '("advise offering the candidate a junior faculty position"))
Now, use the label within the query:
(advise nil junior 'interactive)
MISCELLANEOUS
The pretty-printing feature implemented in the PPRINT.LSP file is used by typing (pp function-name) and pressing [Return], where "function-name" is the name of any function not built in. This is indispensible when debugging your programs- just try to read a function definition rendered by the regular print function. You can also use PPRINT.LSP to pretty print any list, both within a running program and from the top-level loop.
There is one error in some versions of the XLISP manual that could prove extremely frustrating. ln Section 4, "BREAK COMMAND LOOP" it is erroneously stated that invoking the QUIT function within a break loop will return to the next higher level, eventually reaching the top level loop again. This is not the case. You must press Control G to do this. QUIT is not defined and will just get you into the next lower break loop if you try to use it.
AI PRODUCTS FOR THE ST
In early June, the following AI products were available or under development for the ST.
XLlSP: For the ST, the only LISP actually available at this writing was version 1.5b of XLISP an excellent and well- regarded public-domain interpreter by David Betz. This, the first ST version, was ported to the ST by J R Bammi in 1985. It is written completely in C, and has been implemented on all the popular 16-bit microcomputers as well as under the MS-DOS and UNIX operating systems. XLISP includes extensions for object oriented programming, but no compiler is currently available. XL1SP is available in Data Library 3 of the ATARI16 Forum on CompuServe, as well as from user groups and Antics public domain library. Be sure to get all the documentation files, and the C, source code if you're interested.
CAMBRIDGE LISP: Meracomco is porting their AmigaLISP package to the ST, and it should he available soon through The Catalog. The Cambridge dialect is somewhat different from Common LISP, the emerging standard, but it has a good reputation among those who use it extensively.
Metacamco
5353E Scotts Valley Drive
Scotts Valley, CA 95066
(408) 438-7207
(Expected available through The Catalog; no price set)
CIRCLE 227 ON READER SERVICE CARD
PERSONAL PROLOG: This long-awaited PROLOG environment
for the ST from Optimized Systems Software should also be completed by
now. According to OSS, it will use a full GEM multiwindow environment,
with incremental compilation and interactive program development and testing.
PROLOG programs will have access to TOS services including GEM.
Optimized Systems Saftware, Inc.
1221B Kentwood Avenue
San Jose, CA 95129
(408) 446-3099
$74.95
CIRCLE 228 ON READER SERVICE CARD
EXPERT OPINION: This first expert systems shell for the
ST was developed by Mindsoft of France using Modlula-2, and is available
through The Catalog. It too makes use of the GEM interface. I include it
here because it is really just a programming language, or at least an Al
tool, that is specialized for producing expert systems. Expert Opinion
is as powerful as most of the MS-DOS packages currently available, and
is especially suitable for experimenting and prototyping larger systems.
The Catalog
524 Second Street
San Francisco, CA 94107
(800) 443-0100 Ext. 133
$99.95
CIRCLE 229 ON READER SERVICE CARD