merits of Lisp vs Python
Alex Mizrahi
udodenko at users.sourceforge.net
Mon Dec 11 07:59:44 EST 2006
(message (Hello 'Paul)
(you :wrote :on '(11 Dec 2006 04:14:20 -0800))
(
??>> optimizing language. i think it's called trampolined style.
??>> example can be found in PAIP book: interpreter of Scheme is
implemented in
PR> This book doesn't seem to be online. But anyway I think you mean,
PR> compile the Scheme code into one giant CL function, which is no longer
PR> really a clean mapping of Scheme to CL, it's just writing an
PR> interpreter. And I think that interpreter has to do its own
PR> management of environments rather than letting the CL runtime do it.
PR> So basically it says CL is turing-complete and can do everything,
PR> which we already knew ;-).
point is that writting some custom interpreter in CL is very easy AND you
can still use all other features of CL AND communicate with other DSLs.
PR> the different macros being used. But I think I understand one part of
PR> what was confusing me before: your call/cc macros depend on a
PR> nonstandard feature of some CL implementations.
no, it's standard Common Lisp. it's an ARNESI library. it's very standard --
i was able to run non-modified code in Armed Bear Common Lisp implementation
(it's running on JVM), that is very new and does not fully support the
standard -- but nevertheless, CPS code runs out of the box on it.
PR> You can't write a call/cc macro in standard CL--you instead have to
PR> write something that transforms the entire program.
yes, i cannot write just call/cc -- i should wrap code into with-call/cc.
with-call/cc macro performs transformation of the code to CPS -- and then
call/cc is enabled.
i can enable call/cc for specific functions -- i define them with defun/cc
instead of defun. so, i can define both normal CL functions and call/cc
enabled functions. typically, call/cc is required only in a few pieces of
program where interrupts come, so it's OK.
if i'm going to support generators, i only need to run CPS tranformation on
the body of generator function -- that will tear it in yield points.
PR> I think even with TCO though, you still can't do coroutines with CL
PR> macros (but you can do them with real call/cc). The point is that you
PR> have to do something like TCO on calls that are not tail calls and
PR> actually have to return. You again have to transform the whole
PR> program, not just expand a call/cc macro locally inside functions that
PR> use it.
i think only functions that are coroutines should be fully transformed.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
More information about the Python-list
mailing list