One day a student came to Moon and said, "I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons."
Moon patiently told the student the following story -- "One day a student came to Moon and said, "I understand how to make a better garbage collector..."
Lisp compilers came into existence relatively early after interpreter, because of performance. And early compilers and interpreters had important differences in semantics, what everyone today means by "lisp" was in that day the behavior of compiled code, not interpreted (ie. dynamic vs. lexical scoping). The real value of first implementations of scheme was that they had shown that same semantics as were implemented by lisp compilers could be implemented by reasonably fast interpreter. And today there is Newlisp which has impressive performance for interpreted implementation, because it implements similar semantics as early interpreted lisps.
An entire page of how they were trying to implement in various ways, including FORTRAN.
Then, suddenly:
"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 first attempt at a compiler was made by Robert Brayton, but was unsuccessful. The first successful LISP compiler was programmed by Timothy Hart and Michael Levin. It was written in LISP and was claimed to be the first compiler written in the language to be compiled.
However you look at it, lisp seems to be an exercise in recursion :-)
I think that's the root of what made Lisp different: building a bootstrap implementation in another language was not difficult(1), so implement more complex language features in Lisp itself was possible.
If you take this further, it's quite a powerful concept: since even fairly primitive language features are implemented in a high-level and you can manipulate the AST much like you can manipulate any other data structure, you can change the language in non-trivial ways to suit your problem.
Chapters 4 and 5 of SICP demonstrate this in detail and introduce metalinguistic abstraction not only as a powerful technique in it of itself, but as a technique for teaching students about many other aspects of computer science (introducing a register-based virtual machine, compilation, and garbage collection -- all without leaving a higher-level language):
(1) Shameless plug: here's my own implementation in OCaml based in part on jmc.lisp by pg and on a C implementation by another HNer -- https://github.com/afeinberg/ocaml-tinylisp
The big insight of the very first lisp is that treating everything as a symbol (pointer) together with conditionals and functions is good enough for almost everything, and it is as elegant and complete as Lambda Calculus.
The pair of functions at the very core of a Lisp - eval and apply - has a deep correlation with philosophy, and captured the essence of the general process called interpretation.
Since then lots of things happened, most notably, use of parenthesis to unify the notation (and representation) of code and data for the reader function(s), which, as a consequence, makes macros possible. With macros everything was possible, so CLOS and other "monsters" were created.
Lisp, perhaps, is the greatest example of how a few selected ideas (very clever ones) could be put together to create something exceptional (and beautiful) and, on the other hand, more subtly, how it is not possible to create an ideal (unfortunately, not everything is a list, and by adding new data structures the beauty fell apart), how implementation is always clumsy and cumbersome (all those ugly machine types deep inside) and how crowd of mediocrity quickly produces piles of crap.
22 comments
[ 2.0 ms ] story [ 60.3 ms ] thread(hmmm, maybe it would be a bit spammy if I recursed this statement several more times.)
Moon patiently told the student the following story -- "One day a student came to Moon and said, "I understand how to make a better garbage collector..."
The interpreter was written in Lisp. It was compiled by a human. A Lisp compiler did not come into existence until a long time later.
Then, suddenly:
"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."
http://www.csse.monash.edu.au/courseware/cse3323/CSE3323-200...
http://www-formal.stanford.edu/jmc/history/lisp.ps
http://www-formal.stanford.edu/jmc/history/lisp.tex
The original HTML doesn't reproduce any of the TeX "special" bits like greek letters or mathematical formulae, so the PS is definitely recommended.
However you look at it, lisp seems to be an exercise in recursion :-)
http://www.paulgraham.com/rootsoflisp.html
http://lib.store.yahoo.net/lib/paulgraham/jmc.ps (I noted Preview.app was having transient issues loading this specific postscript file, so I converted it to pdf -- http://behemoth.strlen.net/~alex/jmc.pdf )
Most important, here's the code a Lisp interpreter in Lisp:
http://ep.yimg.com/ty/cdn/paulgraham/jmc.lisp
I think that's the root of what made Lisp different: building a bootstrap implementation in another language was not difficult(1), so implement more complex language features in Lisp itself was possible.
If you take this further, it's quite a powerful concept: since even fairly primitive language features are implemented in a high-level and you can manipulate the AST much like you can manipulate any other data structure, you can change the language in non-trivial ways to suit your problem.
Chapters 4 and 5 of SICP demonstrate this in detail and introduce metalinguistic abstraction not only as a powerful technique in it of itself, but as a technique for teaching students about many other aspects of computer science (introducing a register-based virtual machine, compilation, and garbage collection -- all without leaving a higher-level language):
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#...
(1) Shameless plug: here's my own implementation in OCaml based in part on jmc.lisp by pg and on a C implementation by another HNer -- https://github.com/afeinberg/ocaml-tinylisp
The pair of functions at the very core of a Lisp - eval and apply - has a deep correlation with philosophy, and captured the essence of the general process called interpretation.
Since then lots of things happened, most notably, use of parenthesis to unify the notation (and representation) of code and data for the reader function(s), which, as a consequence, makes macros possible. With macros everything was possible, so CLOS and other "monsters" were created.
Lisp, perhaps, is the greatest example of how a few selected ideas (very clever ones) could be put together to create something exceptional (and beautiful) and, on the other hand, more subtly, how it is not possible to create an ideal (unfortunately, not everything is a list, and by adding new data structures the beauty fell apart), how implementation is always clumsy and cumbersome (all those ugly machine types deep inside) and how crowd of mediocrity quickly produces piles of crap.