People often confuse the printed representation of Lisp with its
actual representation. That is, Lisp functions are lists with the
symbol lambda as its car. It happens that the common Lisp readers use
a fairly direct representation of Lisp functions, namely the body of a
defun function. However, one could imagine a defun-algol function
that translates algol like syntax to Lisp functions. Additionally,
one could have a print-algol function that would coerce Lisp functions
into algol like print representations.
I think of Lisp as a algorithmic assembler. It allows the programmer
to deal with the issues of a problem without getting involved in the
details of a specific machine. Often times, its useful to implement
a new language on top of Lisp to provide data abstraction. A rule
based expert system comes to mind.
Its easy to translate into Lisp from a language using another syntax.
The reverse is in not true. Especially with advent of aggresive
automatic translators. Which for example, prove whether or not
a binding can be allocated on a stack instead of a heap (in a Lisp to C
translator).
The only other type of language that provides this level of
functionality are stack oriented languages. I find them more
difficult to understand -- perhaps because they don't have all the
development tools that other languages have.
IMHO,
Eric
Eric
······@ssl.berkeley.edu