1. Abstract 2. Introduction 3. The LISP Language

LISP as an Environment for Software Design: Powerful and Perspicuous Robert L. Blum and Michael G. Walker Computer Science Department, Stanford University Stanford, California 94305

1. Abstract The LISP language provides a useful set of features for prototyping knowledge-intensive, clinical applications software that Is not found in most other programing environments. Medical computer programs that need large medical knowledge bases, such as programs for diagnosis, therapeutic consultation, education, simulation, and peer review, are hard to design, evolve continually, and often require major revisions. They necessitate an efficient and flexible program development environment. The LISP language and programming environmerts built around it are well suited for program prototyp'ng. The lingua franca of artificial intelligence researchers, LISP facilitates building complex systems becausc It Is simple yet powerful. Because of Its simplicity, USP programs can read, execute, modify and even compose other LISP programs at run time. Hence, it h3as been easy for system developers to create pr.gramming tools that greatly speed the program c 3velopment process, and that may be easily extende'i by users. This has resulted In the creation of many useful graphical Interfaces, editors, and debuggers, which facilitate the development of knowledge-intensive medical applications.

Interface will change. Similarly, administrative and

political changes often force revisions of administrative

software. It is clear that the development of complex medical software requires programming environments that facilitate rapid prototyping and continuing program modification. The virtues of Lisp systems emanate from a) the language itself, b) LISP programming tools, and c) graphical user interfaces. Certain features of the language Itself greatly facilitate the development of programming tools and Interfaces - not only those that are built into the environment but also those that a user may choose to develop for his own application. The syntax is simple - Lisp programs can be easily composed and decomposed and executed by other Lisp programs at run-time. Data types and declarations may be ignored, if one so chooses. The Lisp programming style - composing functions from many other functions - lends Itself to clarity and perspicuity. In this paper we will expand on these features. Shell [5] and Bobrow [6] present further discussions of features that are desirable for knowledge-intensive applications, or applications otherwise subject to 111understood or rapidly changing requirements.

3. The LISP Language LISP Is particularly effective as a symbol processing language. That Is, it provides useful tools for manipulating sentences and words, matching patterns, storing associations, and other symbolic tasks. In contrast are the numeric processing tools (such as specialized array functions) of a language like FORTRAN. This Is significant because clinical medicine depends very heavily on concepts In the form of words and associations, such as lists of symptoms, differential diagnoses, likely causes of an anomalous lab value, or organs perfused by a particular blood vessel. LISP has very simple syntax. Everything is in the form of a list. There are no commas, colons, slashes or other special symbols, except the left and right parentheses () that mark the beginning and end of a LISP program. Spaces are not significant. The only special thing is that the first element of a list Is interpreted as a function (prefix notation). Every LISP program looks like this:

2. Introduction Our goal In this article Is to show the features of LISP that make it an excellent environment for the development of certain kinds of medical software. The concepts and arguments have been expressed previously in LISP manuals and in technical reports on the development of programming environments; we seek here to gather those Ideas most relevant to the development of programs to aid the clinical practice of medicine. An Introduction to the LISP language and to knowledge-based or expert systems can be found In [1] and [2]. We are primarily concemed with programs that deal with medical content (diagnoses, therapies, histories, lab results) as opposed to routine administrative programs. However, administrative programs share similar needs for ease of development and modification; the capabilities of LISP are still relevant. Practitioners who have seen medical artificial intelligence programs, for example the collections In [3] and [4], recognize the opportunity to use medlcal knowledge in their programs. Programs that makes conclusions based on medical knowledge must of necessity evolve over time. Medicine changes: the underlying knowledge changes, the manner in which the data are gathered, stored, and used by a program will change, and the output requirements and user

(FUNCTION-i ARGUMENT-i ARGUMENT-2 ...)

So (PLUS 2 5) is a LISP program that returns the value 7. The first element in the list is the function PLUS. All elements after the first element are arguments to the function, so 2 and 5 are arguments to the function PLUS, which adds them together and returns the value 7.

326 01 95-4210/86/0000/0326$01 .00 K 1986 IEEE

Functions can be arbitrarily nested, so, for example, ARGUMENT-i above can be replaced with

functions. This is, In fact, how expert systems tools such as KEE, ART, S.1, and EMYCIN have been built. Every one of these tools Is a special purpose application language written in, or on top of, LISP. Statements in KEE and the other tools are actually USP code that Is evaluated by the underlying LISP Interpreter. As the user and programmer gain more understanding of the problem, the special purpose language for the user's application evolves. We'll look next at how readily an Interpreter for a language can be built.

(FUNCTION-2 ARGUN ENT-3 ARGUIENT-4)

so that we get: (FUNCTION-1 (FUNCTION-2 ARGNENT-3 ARGUMENT-4) ARGUNENT-2 ... )

To do this with (PLUS 2 5), we could replace the 2 with (TIMES 2 3) to get (PLUS (TIMES 2 3) 5) which returns 11.

6. EVAL: New Language Interpreters One LISP function Is crucial In providing the ability to treat programs as data: the function EVAL. EVAL makes It easy to build special purpose language Interpreters such as KEE and the other expert system tools. EVAL is a way of invoking the LISP language Interpreter to EVALuate an arbitrary LISP expression. For example, (EVAL (LIST 'PLUS 2 5)) Is Interpreted as follows. First, the function LIST In (UST 'PLUS 2 5) takes Its three arguments, PLUS, 2, and 5, and wraps them up in a list: (PLUS 2 5). The function EVAL tells the Interpreter to EVALuate (PLUS 2 5), which retums the value 7. The effect of this Is the same as typing (PLUS 2 5) at the LISP prompt, except that we can construct the pieces of the program on the fly and evaluate it when we want. A more meaningful use of EVAL Is In building a rule Interpreter for an expert system. Let's look at how this Is done. Most expert systems use rules of the form:

4. Minimizing Constraints A major development constraints development.

advantage of LISP as a program environment is that It does not impose in unnecessarily early program This helps reduce and defer the effort required to make major changes In program design, as often occurs as needs are better understood or otherwise change. USP gives the programmer the chotce of whether or not to declare data types. This option allows the programmer to develop a prototype without all the pain of declarations at the outset, but allows declarations to be added later to gain efficiency at compilation time. Early in the design stage, program developers are more Interested In expressing the desired functionality of the program than they are In Its efficiency. LISP ailows the type of a variable to be determined at the time It Is used, rather than forcing data types to be declared at the outset. The developer li free to use simple, possibly Inefficient data structures such as linked lists that allow the program to be developed quickly, and to change the data type later to whatever proves to be most efficient. When the program Is nearing the stage of actual release, LISP provides facilities for making the desired data declarations. If a programming language requires that all data types be specified before the program can be run, It delays the time when the user can see and evaluate a functioning prototype, and In addition makes It more difficult to change the Implementation rapidly In any major way.

IF

the apple is red THEN assert that the apple is ripe

Two very simplified medical rules for urinary tract Infections might be: IF

the patient is immunosuppressed and bas mycelia in the urine THEN assert that the urinary organism is a fungus

5. Programs Equal Data One of the most useful and important features of LISP is that programs and data are equivalent. Specifically, a LISP program may be used as Input (i.e., used as data) by another LISP program, and a LISP program may produce yet another LISP program as output. We will see later how this feature is used In debugging tools, but first lets see how it facilitates the definition of special purpose application languages. The equivalence of programs and data makes It very easy to create Interpreters for special purpose languages. The programmer can use LISP to design a

IF

the patient is receiving chronic chemotherapy or chronic steroids THEN assert that the patient is immunosuppressed

As in traditional logic, the clause following the "IF", I.e., "the apple is red", is called the premise. The clause following the "THEN", i.e., "the apple is ripe", is called the conclusion. Typically, large numbers of such rules are linked together in rule-based expert systems to perform diagnosis or other tasks. Note how the of medical the second rule conclusion - immunosuppressed - is used in the premise of the

new, special purpose language (for example the rule language commonly used In expert systems) in which the user can express his problem. Because statements In the special purpose language can be treated as LISP lists, they can be evaluated as programs by LISP

327

first medical rule. This is called rule chaining, and it Is the basis of reasoning in rule-based systems. The main advantage of using rules is that It gives the physician an easier way of expressing his knowledge in a computer-understandable form. However, neither LISP nor any other conventional programming language can immedrately understand rules. (PROLOG is the exception that has a built-in rule Interpreter.) We need a new, special purpose interpreter that can understand rules and use them to reach conclusions. In effect, we want to create a new application language - rules - that lets the user say what he wants to say in a more natural form. LISP, and particularly the function EVAL, makes it very easy to build this new language. The essential job we want this new rule interpreter to do is this: IF

because it provides such a flexible and rapid development environment, LISP has long been the dominant language for artificial intelligence research. We have seen a few of the characteristics of the LISP language that make it attractive: simple syntax, minimization and delay of design constraints, the ability to easily prototype special purpose application languages based on EVAL and the equivalence of programs and data, and facility for symbolic, as opposed to numeric, reasoning. These characteristics are present no matter which dialect of LISP you choose. We'll next look at the support provided by tools that are part of the programming environment of better LISPs, but which are not included in every dialect or implementation.

7. The Lisp Programming Environment In this section we examine some of the features of the LISP programming environment. Because LISP Is composed of lists that LISP Itself Is deslgned to parse, It can read and understand itself. This ability of LISP to treat its own programs as data makes It possible to build intelligent programming tools In LISP. The Masterscope program, for example, is written In Interlisp, and Is designed to analyze other LISP programs [7]. Masterscope analyzes user functions to determine which other functions are called, how and where variables are bound, set, or referenced, and Information on data declarations. It produces a database of the results of Its analysis, and points out various programing errors such as unbound variables. The user Is provided with a simple query language that provides both textual and graphic displays of the data. In additlon, the programmer can use the Masterscope database under program control to change his code at all occurrences of a variable, or when some conditlon exists. The Masterscope program is most valuable to the programmer who inherits responsibility for maintaining and modifying code developed by another. Given that code Is almost never adequately documented, the ability to automatically generate a Masterscope analysis of a large program can save days of effort In determining how a program works (or why It doesn't). There are many other examples of LISP programs that manipulate other LISP programs. The Interlisp editor is itself a LISP program. It Is possible to invoke the LISP editor inside another program so that extensive changes can be made automatically. This can be used both by the Masterscope program described earlier, and by user programs to automatically modify or generate code. Another very useful feature of LISP, though one that It shares with many other languages, is that It can be either Interpreted or compiled. Traditionally, languages such as PASCAL, PL/1, COBOL, and FORTRAN require numerous steps before a program can be executed. First the programmer must use an editor to create the code, then a compiler to translate the program into machine language, then a linker to produce an executable form, and finally must execute the program. An error at any stage may require the programmer to go back to step one, correct the error, and restart the sequence. Interpreted languages like LISP, on the other

the the rule premise Is true

THEN

assert that the rule's conclusion Is true.

For the sake of simplicity, we will assume that the premise and conclusions of rules can be fetched using a USP function GET, and that conclusions are all of the form (ASSERT fact). Using EVAL, we can write the LISP Interpreter that will perform this Job: (DEFINEQ INTERPRET-RULE (RULE) (IF

( EVAL (GET RULE 'PREMISE)) TH N (EVAL (GET RULE 'CONCLUSION))

INTERPRET-RULE works as follows. It first fetches the premise of the rule, by doing (GET RULE 'PREMISE). It then EVALuates the premise to determine if it is true. If the premise is true, INTERPRET-RULE fetches the conclusion of the rule, by doing (GET RULE 'CONCLUSION). It EVALuates the conclusion, performing the specified ASSERT. If the premise was not true, the rule would have failed, and no assertion would be made. This particular type of interpreter implements what is called forward rule chaining, because the premise is evaluated before the conclusion is evaluated. The process can also be reversed. Expert systems, or systems that use knowledge in an attempt to emulate the performance of a human expert, are arguably the most difficult systems to build from a design point of view. The prime reason is the difficulty of determining (in an algorithmic form) what an expert knows and how he reasons with what he knows to reach a conclusion. Thus, it is very difficult to specify what the computer program should know and how it should reason. Standard techniques for program development, such as structured or top-down design, encounter problems when applied to expert system development, because the task is only vaguely specified and the algorithms are poorly understood. Building expert systems requires a very flexible development environment that allows many different designs to be rapidly tested and modifled. Precisely

328

make it easy to see several Interacting parts on the screen at once; one window can display source code, another can display the program output, a third can contain a trace of key variables, a fourth can display a data structure that is being debugged, and so on. Relations between program components can be readily displayed in graphic form. The Activelmages program for Intelligent displays, Included In the KEE Knowledge Engineering Environment from Intellicorp [8], and the Steamer Interactive, graphic, training simulator [9], provide two examples of how visually attractive and cognitively appealing user Interfaces can be built by combining the power of LISP-based systems with high-resolutlon graphics.

hand, execute the program as soon as the last line of code Is typed, and the user gets Immediate feedback. The LISP compiler need only be Invoked when program development is complete and the user Is ready to produce a fast version. In addition, LISP takes advantage of its Interpreted environment to provide a valuable set of program development tools. Among these are the ability to step through execution of a program, or fragments of a program, without spending any time compiling and linking. The user can write a small piece of code that Is to form part of his final program and immediately test It and modify It, In seconds rather than minutes. It Is possible to Inspect the stack of variable bindings at any time during program execution, so sources of bugs can be very rapidly located. The bindings of variables can be changed during execution when the program breaks because of an error, or when the user requests a break. This Is particularly useful when very long programs break near their end because a trivial error was made. Within a break It Is possible to redefine functions, open files, redefine records, analyze function calls, or In fact to perform any LISP activity that can be performed at the top level. The full power of the language Is available at the instant that the program Is running and the break occurs. It Is very advantageous to be able to correct the error on the fly and allow the program to resume without re-doIng all Its previous work. Often, their are many bugs within a single program, and they may all be corrected In one execution of the program, rather than repeatedly rerunning the program from the beginning to find the next bug. The trace package provides a simple means of tracing the execution of all function calls, along with the bindings of their formal parameters, at run time. This "window" Into the program execution greatly simplifies finding when and where errors originate. It Is also routine to run both Interpreted and compiled lisp functions In the same core. Thus, portions of the code that are stable may be run compiled to speed performance, while the parts that are undergoing change can run interpreted so they can be readily modified.

9. Current Status of LISP

We will next consider the current status of the language In terms of variations across dialects and machines, and matters such as speed and longevity of the language. USP has been the dominant language In artificial intelligence research for over twenty-five years. It Is one of the oldest programming languages; Invented In the late 50's, by Professor John McCarthy, then at MIT, LISP is just a little younger than FORTRAN. It is the language of choice for applications In expert systems, and widely used for natural language understanding, robotics, and vision systems. At the time of writing (1986), several companies, such as Xerox, Symbolics, and LMI, sell systems designed exclusively to support LISP. Major computer manufacturers Including IBM, Digital Equipment, Hewlett-Packard, Control Data, and others support LISP on their machines. Some companies, such as Texas Instruments, have Implemented VLSI chips specifically designed to run LISP, resulting in very fast execution. The Defense Advanced Research Projects Agency has long been a major supporter of Al projects, most of whom use LISP, and the DOD Is substantially Increasing Its funding for Al applications, as well as supporting adoption of a standard LISP dialect, described below. It is necessary to note that there are several dialects of LISP, and that versions on small machines may be missing some of its features. The most advanced dialects are lnterlisp and Zeta Lisp, both of which provide tools and facilities like those we will describe here. Other dialects, such as Franz Lisp, MacLisp, Portable Standard Lisp (PSL), Scheme, and others were Implemented with different goals in mind, like running on small machines or in less core, and thus lack many features. Implementations on microcomputers, described below, have historically been particularly impoverished, though this situation is Improving. Thus, the reader must be wary in selecting a LISP dialect to ensure that the desired features are

8. Graphical Interface

Another Important component of the LISP programming environment is the use of bit-mapped graphic displays to provide novel programming tools. As Is often said, a picture Is worth a thousand words, and Interlisp has emphasized the development of graphic programming tools. Many of the features now found on microcomputers like multiple windows, menus, function Icons, general graphics Interfaces and objectoriented displays were first fully worked out on LISP workstations. Unfortunately, the graphics In many mainframe and minicpmputer programming environments are Inferior to those now available on microcomputers, which themselves lag the development of graphic Interfaces on LISP machines. Built-in windowing, menu, and other graphics capabilities developed on LISP machines and now familiar to microcomputer users make It easy to construct a prototype Interface that the user can critique immediately, rather than several weeks or months after programming has begun. Multiple windows

Included.

In the past three years a new dialect, called Common Lisp, has begun to emerge as a standard [10]. Common Lisp was developed by a large group of experienced LISP programmers who had worked in other dialects, and recognized the need for a portable, standardized version. Considerabletheimpetus to this Department of movement has been provided by

329

Among the automatic programming projects, the more advanced include the CHI and REFINE systems, which originated under the direction of C. Green, now at the Kestrel Institute [15]. These programs have been designed to transform high-level specifications of problems Into efficient Implementations. For example, the prototype CHI compiler was synthesized from a high-level description of Itself. This work has recently moved Into the commercial environment with the establishment of Reasoning Systems, Inc. to market the REFINE knowledge-based software environment. Related work by Barstow at Schlumberger-Doll [16] has produced an experimental system that automatically performs maintenance of certain parts of large, frequently changing FORTRAN programs used In analysis of geophysical data for oll exploration. Kant at Carnegie-Mellon has been concerned with understanding and automating the cognitive processes involved in program synthesis [17]. This effort to understand better the nature of programming is likely to suggest new functions that can be added to existing programming environments. It is Ironic that early papers that use the phrase "automatic programming" actually describe the development of the first FORTRAN compilers in the 1950's [18]. However, when we realize that those compilers were concemed with taking a "high level" and "easily understandable" program specification (In FORTRAN), and translating It automatically into machine code, we see that the problem is still much the same. We're simply advancing to higher, more abstract, Initial problem specifications, and letting the computer make more and more of the low-level decisions. This is an appropriate goal for research on knowledge-based programming.

Defense, which has begun to require the use of Common Lisp in its artificial Intelligence contracts. Most of the major Lisp machine manufacturers now supply Common Lisp on their machines. Recently, LISP has also grown In popularity on microcomputers. Subsets of major dialects Including Common Lisp, MacLisp and lnterlisp have been Implemented, as well as a large number of dialects specific to micros, Including muLisp, TLC-LISP, IQLISP, ExperLisp, and MacScheme. Prices of the micro versions range from about $100 to $500. The quality of the implementations vary greatly, and many features are missing in micro versions. Kahane [11] provides a useful review of three of the better-established micro LISPS including benchmarks. Until recently, inadequate memory has been a serious handicap to Implementing all the features of a full-scale LISP environment on micros, because, naturally enough, more features take more room. The movement to larger address spaces and more on-board RAM has helped alleviate this problem, and we can expect substantial Improvement In the micro LISPs. Lisp also has a reputation as a slow language, particularly for numeric computation. This has changed dramatically In recent years as better compilers have been written, and more efficlent versions of LISP have been written. LISP can now perform numeric computations at rates comparable to FORTRAN on the same processors. To illustrate the current capability of the language, In the XEROX LISP workstations Interlisp is used for the operating systems, I/O drivers, graphics interface, and the data communications (Ethernet)

Interface.

10. Knowledge-Based Programming Environments

1 1. Conclusion

The LISP programming environment Is by no means fixed. Considerable research Is being devoted to applying artificial Intelligence techniques to the problems of software development. This generally falls under the two topics of intelligent programmer's assistants and automatic programming. A good Introduction to these topics can be found In the IEEE Transactions on Software Engineering Special Issue on Artificial Intelligence and Software Engineering [12]. Barstow [13] provides a number of interesting examples of Intelligent, LISP-based programming environments. Existing programming tools, for the most part, help the user by handling clerical tasks, graphic display, and syntax problems. They do not help "absorb complexity" by taking over some of the Intellectual tasks. This Is one of the goals of research on intelligent programmer's assistants. These tools use explicit onThis line knowledge about software engineering. distinguishes them from programs like conventional editors that do not reason about the actions they take; such programs Just follow orders. The Programmer's Apprentice is one of the more advanced intelligent The prototype Knowledge-Based assistants [14]. Editor In Emacs (KBEmacs), a component of the Programmer's Apprentice, has been able to reduce the number of commands necessary to create a program by as much as an order of magnitude.

LISP can be a good choice for medical programs that depend on medical content, such as programs for education, simulation, peer review, monitoring systems, diagnosis and therapy. Its features also make It attractive as a development environment for programs that have poorly understood or rapidly changing requirements. Prime features of the language include a simple syntax, minimization and delay of design constraints, the ability to easily prototype special purpose application languages based on the equivalence of programs and data, and the ability to facilitate symbolic, as opposed to numeric, reasoning. The better LISP programming environments include Interactive program analysis and debugging tools that greatly speed program development, and high resolution graphics used by intelligent program development tools to more effectively convey static and dynamic program structure. Current artificial Intelligence research In knowledge-based programming environments shows considerable promise for the development of tools that absorb much of the complexity of programming by explicitly storing and machine-readable of using knowledge-bases programming techniques.

330

References 1. Walker, M.G., and Blum, R.L. "A Lisp Tutorial." MD

15. Smith, D.R., Kotik, G.B., and Westfold, S.J. "Research on Knowledge-Based Software Environments at Kestrel Institute." IEEE Transactions on Software Engineering SE-11, 11 (November 1985), 1278-1295.

Computing 2, 1 (1985), 56. 2. Walker, M.G., and Blum, R.L. "Minimycin: A Miniature Rule-Based System." MD Computing 2, 4 (1985), 21.

16. Barstow, D. "A Persective on Automatic

Programming." Al Magazine 5, 1 (Spring 1984), 5-27.

3. Clancey, W.J., and Shortliffe, E.H.. Readings in Medical Artificial Intelligence: The First Decade. Addison-Wesley, 1984.

17. Kant, E. Understanding and Automating Algorithm Design. Proceedings of the International Joint Conference on Artificial Intelligence, IJCAI, 1985.

4. Reggia, J.A., and Tuhrim, S.. Computer-Aided Medical Decision Making, Volume 2. Springer-Verlag, 1985.

18. Backus, J.W. Automatic Programming - Properties and Performance of FORTRAN Systems I and 11. Symposium on the Mechanisation of Thought Processes, National Physical Laboratory, Teddington, Middlesex, England, 1958.

5. Shell, B. "Power Tools for Programmers." Datamation (February 1983), 131-144.

6. Bobrow, D.G. "If Prolog is the Answer, What is the Question? or What It Takes to Support Al Programming Paradigms." IEEE Transactions on Software Engineering SE-I1, 11 (November 1985), 1401-1408.

Acknowledgments The authors have been supported through funding of the RADIX project by the National Library of Medicine (grant LM-04334) and by the National Science Foundation (grant IST-8317858). Previous funding was provided by the National Center for Health Services Research through grant HS-04389, by the NLM through grant LM-03370, and by the Pharmaceutical Manufacturers Association Foundation. This work was performed using facilities provided by SUMEX-AIM, which is funded by NIH grant RR-00785 from the Biotechnology Resources Program.

7. XEROX Corporation. lnterllsp Reference Manual. XEROX Special Information Systems, Pasadena, Calif., 1983.

8. Fikes, R, and Kehler, T. "The Role of Frame-Based Representation in Reasoning." Communications of the ACM 28, 9 (September 1985), 904-920. 9. Hollan, J.D., Hutchins, E.L., and Weitzman, L. "STEAMER: An Interactive Inspectable Simulation-Based Training System." Al Magazine (Summer 1984), 15-27.

10. Steele, G.L. Jr.. Common Lisp Reference Manual. Digital Press, Bedford, Massachusetts, 1984. 11. Kahane, S.N., and Johannes, R.S. A Comparison of Three LISP Interpreters for MS-DOS-Based Microcomputers. Proceedings of the Ninth Annual Symposium on Computer Applications in Medical Care, IEEE Computer Society Press, Washington, D.C., 1985, pp. 186-192.

12. Mostow, J., Guest Editor. "Special Issue in Artificial Intelligence and Software Engineering." IEEE Transactions on Software Engineering SE-11, 11 (November 1985), . 13. Barstow, D., Shrobe, H., and Sandwell, E., (Eds.). Interactive Programming Environments. McGraw-Hill, New York, 1984. 14. Waters, R.C. "The Programmer's Apprentice: A Session With KBEmacs." IEEE Transactions on Software Engineering SE- Il, 11 (November 1985), 1296-1320.

331