Professional Documents
Culture Documents
Lisp 20 TH
Lisp 20 TH
Lisp 20 TH
FUTURE1980
John McCarthy
Computer Science Department
Stanford University
Stanford, CA 94305
jmc@cs.stanford.edu
http://www-formal.stanford.edu/jmc/
1999 Mar 22, 5:09 p.m.
Abstract
LISP has survived for 21 years because it is an approximate local optimum in the space of programming languages. However, it
has accumulated some barnacles that should be scraped off, and some
long-standing opportunities for improvement have been neglected. It
would benefit from some co-operative maintenance especially in creating and maintaining program libraries. Computer checked proofs
of program correctness are now possible for pure LISP and some extensions, but more theory and some smoothing of the language itself
are required before we can take full advantage of LISPs mathematical
basis.
1999 note: This article was included in the 1980 Lisp conference
held at Stanford. Since it almost entirely corresponds to my present
opinions, I should have asked to have it reprinted in the 1998 Lisp
users conference proceedings at which I gave a talk with the same
title.
Introduction
2. Formac was another Fortran based language that was pushed for a
while by part of IBM. It was dedicated to manipulating a class of
algebraic formulas written in Fortran style and was also oriented to
batch processing.
3. Formula Algol was dedicated to the linguistic pun that the elementary
operations can be regarded as operating on numbers or on formulas.
The idea was that if a variable x has no value, then operations on
expressions involving x must be regarded as operating on the formula.
A few programs could be written, but the pun proved an inadequate
basis for substantial programs.
4. One of the more interesting rivals to LISP is (or was) POP-2. It has
everything that LISP has except that its statements are written in an
Algol-like form and dont have any list structure internal form. Thus
POP-2 programs can produce other POP-2 programs only as character strings. This makes a much sharper distinction between system
programmers and application programmers than in LISP. In LISP, for
example, anyone can make his own fancy macro recognizer and expander.
5. Microplanner is an attempt to make a higher level general purpose language than LISP. The higher level involves both data (pattern matching) and control (goal seeking and failure mechanisms). Unfortunately,
both proved inadequately general, and programmers were forced to
very elaborate constructions, to new languages like CONNIVER with
even more elaborate control features, and eventually many went back
to LISP.
One generic trouble seems to be that no-one adequately understands
pattern directed computation which always works very nicely on simple
examples, but which leads to over complicated systems when generalized. We can see this in LISP in certain macro expansion systems like
that of the LISP machine [WM78].
6. I should mention Prolog, but I dont understand it well enough to
comment. 1
1
1999 note: The ideas of Prolog are similar to a subset of the ideas of Microplanner.
However, Prolog was designed systematically and has survived, while Microplanner didnt.
Improvements
1999: The 1981 ideas have been combined with other ideas, e.g. about speech acts,
and elaborated. See [McC96]. The Elephant idea referred to was to avoid data structures
by allowing direct reference to the past.
4
1999: That textbook didnt appear, mainly because of a difference of opinion among
the authors about the most appropriate proof formalism
5
1999: FOL was succeeded in the Lisp course by Jussi Ketonens EKL prover, but the
proposed integrated system hasnt happened.
6
1999: NQTHM (aka the Boyer-Moore prover) was used by Shankar when he taught the
course. This prover is designed to use induction to prove properties of total Lisp functions.
Using the Eval function of the logic and the representation of function definitions as
Sexpressions properties of partial functions can also be proved. NQTHM has evolved
proofs.
4. No techniques exist for correctness proofs of programs involving lazy
evaluators.
5. Programs with functional arguments are in principle accessible by Dana
Scotts methods, but the different kinds of functional arguments have
been treated only descriptively and informally.9
6. Probably the greatest obstacle to making proof-checking a useful tool is
our lack of knowledge of how to express the specifications of programs.
Many programs have useful partial specifications - they shouldnt loop
or modify storage that doesnt belong to them. A few satisfy algebraic
relations, and this includes compilers. However, programs that interact
with the world have specifications that involve assumptions about the
world. AI programs in general are difficult to specify; most likely their
very specification involves default and other non-monotonic reasoning.
(See [McC80].)
1999: A logic for reasoning about Lisp-Scheme-ML like programs with functions and
mutable data structures has been developed by Mason and Talcott [HMST95]. This logic
has a relatively complete axiomatization of primitives for mutable data as well as a variety
of induction principles and methods for proving properties of programs.
References
Lisp was first described in [McC60] and the first manual was [ML+ 66] the
first version of which appeared in 1962.11
10
1999: An example is Maude [Gro99, CDE+ 98, Wil97], a language based on Rewriting
Logic. In Maude, actions and effects are expressed in a declarative manner, and using
the reflective capability, Maude programs and computations can be represented, reasoned
about, modified and executed in Maude.
11
1999: I thank Carolyn Talcott for additonal references.
10
References
[BM79]
[Car77]
[Gro99]
1999.
See
[Mas86]
[McC60]
11
[McC62]
[McC63]
John McCarthy. A Basis for a Mathematical Theory of Computation12 . In P. Braffort and D. Hirschberg, editors, Computer
Programming and Formal Systems, pages 3370. North-Holland,
Amsterdam, 1963.
[McC80]
[McC81]
John McCarthy. History of lisp. In Richard L. Wexelblat, editor, History of programming languages. Academic Press, 1981.
Reprinted from Proceedings of the ACM Conference on the History of Programming Languages, Los Angeles, 1977.
[McC90]
[McC96]
[ML+ 66]
[Wil97]
[WM78]
Daniel Weinreb and David Moon. Lisp machine manual. Technical report, M.I.T. Artificial Intelligence Laboratory, 1978.
/@steam.stanford.edu:/u/ftp/jmc/lisp20th.tex: begun Mon Feb 1 17:36:27 1999, latexed March 22, 1999 at 5:09 p.m.
12
http://www-formal.stanford.edu/jmc/basis.html
http://www-formal.stanford.edu/jmc/circumscription.html
14
http://www-formal.stanford.edu/jmc/elephant.html
13
12