[EMAIL PROTECTED] wrote:
On Tue, Jan 22, 2008 at 02:07:47PM -0800, Brad Beyenhof wrote:
An important thing to realize here is that Lisp (LISt Processing)
was developed as a way to express mathematical operations, NOT as a
programming language. The fact that interpreters can be used to
evaluate those expressions on a computer is largely incidental
(which explains why there are so many sub-languages and interpreter
implementations out there).
Err, I think Lisp was developed as an alternative to the Turing
Machine notion of computation. So it wasn't completely divorced from
programming even back then.
Theory of computation != programming
McCarthy never intended his lambda calculus to be a programming language.
Quoting the man himself:
http://www-formal.stanford.edu/jmc/history/lisp/node3.html
One mathematical consideration that influenced LISP was to express
programs as applicative expressions built up from variables and
constants using functions. I considered it important to make these
expressions obey the usual mathematical laws allowing replacement of
expressions by expressions giving the same value. The motive was to
allow proofs of properties of programs using ordinary mathematical
methods. This is only possible to the extent that side-effects can be
avoided. Unfortunately, side-effects are often a great convenience
when computational efficiency is important, and ``functions'' with
side-effects are present in LISP. However, the so-called pure LISP is
free of side-effects, and (Cartwright 1976) and (Cartwright and
McCarthy 1978) show how to represent pure LISP programs by sentences
and schemata in first order logic and prove their properties. This is
an additional vindication of the striving for mathematical neatness,
because it is now easier to prove that pure LISP programs meet their
specifications than it is for any other programming language in
extensive use. (Fans of other programming languages are challenged to
write a program to concatenate lists and prove that the operation is
associative).
Another way to show that LISP was neater than Turing machines was to
write a universal LISP function and show that it is briefer and more
comprehensible than the description of a universal Turing machine.
This was the LISP function eval[e,a], which computes the value of a
LISP expression e - the second argument a being a list of assignments
of values to variables. (a is needed to make the recursion work).
Writing eval required inventing a notation representing LISP
functions as LISP data, and such a notation was devised for the
purposes of the paper with no thought that it would be used to
express LISP programs in practice. Logical completeness required that
the notation used to express functions used as functional arguments
be extended to provide for recursive functions, and the LABEL
notation was invented by Nathaniel Rochester for that purpose. D.M.R.
Park pointed out that LABEL was logically unnecessary since the
result could be achieved using only LAMBDA - by a construction
analogous to Church's Y-operator, albeit in a more complicated way.
S.R. Russell noticed that eval could serve as an interpreter for
LISP, promptly hand coded it, and we now had a programming language
with an interpreter.
The unexpected appearance of an interpreter tended to freeze the form
of the language, and some of the decisions made rather lightheartedly
for the ``Recursive functions ...'' paper later proved unfortunate.
These included the COND notation for conditional expressions which
leads to an unnecessary depth of parentheses, and the use of the
number zero to denote the empty list NIL and the truth value false.
Besides encouraging pornographic programming, giving a special
interpretation to the address 0 has caused difficulties in all
subsequent implementations.
Another reason for the initial acceptance of awkwardnesses in the
internal form of LISP is that we still expected to switch to writing
programs as M-expressions. The project of defining M-expressions
precisely and compiling them or at least translating them into
S-expressions was neither finalized nor explicitly abandoned. It just
receded into the indefinite future, and a new generation of
programmers appeared who preferred internal notation to any
FORTRAN-like or ALGOL-like notation that could be devised.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
