On Sat, Jan 12, 2008 at 03:32:15PM -0800, Andrew Lentvorski wrote:
SJS wrote:
begin quoting David Brown as of Sat, Jan 12, 2008 at 01:48:23AM -0800:
Since lisp compiles incrementally, this can be a little unclear.
Um, that's not a /requirement/ for LISP, is it?
No, it is not.
Common Lisp is required to support macros.
That doesn't mean that everything can't be interpreted all the way down.
ie. the expansion of the macro can be done by a sufficiently clever
interpreter.
That's why I said it matters what you mean by "compile". Most do not
directly interpret the SEXP representing even what you type at REPL, but
compile to either some kind of byte-code or directly to assembly.
The spec specifically allows functions to be interpreted or compiled, and
doesn't really define what that means. It only requires 'compiled' to have
all macros expanded and no unresolved references. The compiled code could
be anything between the expanded lambda, bytecode or native code.
Although, you could still call that expansion "incremental compiling".
However, then were arguing semantics rather than features.
Yeah, I think we have a different intuition about the meanings of the words
to the Common Lisp spec.
However, SBCL does compile fully to native code for all evaluations, even
expressions typed at the command prompt.
In addition, I don't think Scheme required support for macros for a long
time. IIRC, SICP doesn't have any mention of macros at all (whoops ...
sorry ... didn't mean to drag the thread back on topic).
Scheme macros postdate SICP. Scheme has hygenic macros, mostly because
scheme only has one binding per symbol (functions and values are in the
same namespace), it is really easy to mess up code by defining new names.
LISP does make it easy to modify running code, right? Just not via the
macro system.
Um, maybe. But then your talking about features of the REPL, not Lisp.
The spec requires COMPILE, so the REPL doesn't need to be involved to
change running code.
The main feature that you normally get from Lisp REPL is the ability to
inject extra code into the system so that you can do useful things after
interrupt/restart. This is not unique to Lisp.
Imagine something, such as an editor, written in lisp that allowed itself
to be modified dynamically. It isn't necessary for the user to ever
interact with the REPL to get the needed functionality, it is just part of
the language. (Yes, I realize that Emacs isn't Common Lisp, but it is
similar).
This is becoming a lot more common now. .NET, Java, Python, Perl and
probably many others, make it fairly easy to have dynamically loaded code.
Dynamically loaded code can be dynamically modified code with something as
simple as a function pointer.
Basically, any language with a well-managed lexical environment that you
can capture would work.
To be fair, you *could* do this even with C. Load new code, adjust the
call stack, slap a return down, and execute. IIRC, the issue is less with
C than with the fact that you are running directly on hardware inside an
OS--one of whose purposes is to prevent arbitrary damage from one running
program to another.
Lisp systems that generate native code have had to solve the same problem
that you would have to do do dynamic code modification in lisp. It
generally involves small snippets of assembly. But, fortunately, they only
have to solve it once, and the rest of us can just use it.
Dave
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
