merits of Lisp vs Python

[Alex Mizrahi]

(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")