STEINBERG@RUTGERS.ARPA (01/04/84)
Herb:
Those are hardly stupid questions. Let me try to answer:
1. Just why is a language like LISP better for doing AI stuff than a
language like PASCAL or ADA?
There are two kinds of reasons. You could argue that LISP is more
oriented towards "symbolic" processing than PASCAL. However, probably
more important is the fact that LISP provides a truly outstanding
environment for exploratory programming, that is, programming where
you do not completely understand the problem or its solutions before
you start programming. This is normally the case in AI programming -
even if you think you understand things you normally find out there
was at least something you were wrong about or had forgotten. That's
one major reason for actually writing the programs.
Note that I refer to the LISP environment, not just the language. The
existence of good editors, debuggers, cross reference aids, etc. is at
least as important as the language itself. A number of features of LISP
make a good environment easy to provide for LISP. These include the
compatible interpreter/compiler, the centrality of function calls, and the
simplicity and accessibility of the internal representation of programs.
For a very good introduction to the flavor of programming in LISP
environments, see "Programming in an Interactive Environment, the LISP
Experience", by Erik Sandewall, Computing Surveys, V. 10 #1, March 1978.
2. What is the significance of not distinguishing between data
and program in LISP? How does this help?
Actually, in ANY language, the program is also data for the interpreter
or compiler. What is important about LISP is that the internal form used
by the interpreter is simple and accessible. It is simple in that the
the internal form is a structure of nested lists that captures most of
both the syntactic and the semantic structure of the code. It is accessible
in that this structure of nested lists is in fact a basic built in data
structure supported by all the facilities of the system, and in that a
program can access or set the definition of a function.
Together these make it easy to write programs which operate on other programs.
E.g. to add a trace feature to PASCAL you have to modify the compiler or
interpreter. To add a trace feature to LISP you need not modify the
interpreter at all.
Furthermore, it turns out to be easy to use LISP to write interpreters
for other languages, as long as the other languages use a similar
internal form and have a similarly simple relation between form and
semantics. Thus, a common way to solve a problem in LISP is to
implement a language in which it is easy to express solutions to
problems in a general class, and then use this language to solve your
particular problem. See the Sandewall article mentioned above.
3. What is the difference between decisions made in a production
system and decisions made in a PASCAL program (in which IF statements
also have the same (superficial) form).
Production Systems gain some advantages by restricting the languages
for the IF and THEN parts. Also, in many production systems, all
the IF parts are evaluated first, to see which are true, before any
THEN part is done. If more than one IF part is true, some other
mechanism decides which THEN part (or parts) to do. Finally, some
production systems such as EMYCIN do "backward chaining", that is, one
starts with a goal and asks which THEN parts, if they were done, would
be useful in achieving the goal. One then looks to see if their
corresponding IF parts are true, or can be made true by treating them
as sub-goals and doing the same kind of reasoning on them.
A very good introduction to production systems is "An Overview of Production
Systems" by Randy Davis and Jonathan King, October 1975, Stanford AI Lab
Memo AIM-271 and Stanford CS Dept. Report STAN-CS-75-524. It's probably
available from the National Technical Information Service.rh@mit-eddie.UUCP (Randy Haskins) (01/07/84)
One of the problems with LISP, however, is it does not force one to subscribe the code of good programming practices. I've found that the things I have written for my bridge-playing program (over the last 18 months or so) have gotten incredibly crufty, with some real brain-damaged patches. Yeah, I realize it's my fault; I'm not complaining about it because I love LISP, I just wanted to mention some of the pitfalls for people to think about. Right now, I'm in the process of weeding out the cruft, trying to make it more clearly modular, decrease the number of similar functions and so on. Sigh. -- Randwulf (Randy Haskins); Path= genrad!mit-eddie!rh