(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") -- http://mail.python.org/mailman/listinfo/python-list