Re: CL implementations and tail-call optimization
- From: Brian Downing <see-signature@xxxxxxxxx>
- Date: Mon, 30 Oct 2006 12:44:58 -0600
In article <1156761645.434767.82780@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Rob Thorpe <robert.thorpe@xxxxxxxxxxxx> wrote:
I've looked at all of the implementations on my machine. All of Sbcl,
Ecl , Clisp and Gcl have TCO in their compilers. The normal
interpreters of Ecl, Gcl and Clisp don't have it (and Sbcl doesn't have
an interpreter).
[Apologies for pulling this thread out of the deep.]
Just as a note, since 0.9.17 SBCL has had a full interpreter. It is not
enabled by default; to use it:
(setf sb-ext:*evaluator-mode* :interpret) ; :compile for default behavior
It is primarily intended for performance of run-once code and eventual
support of compilerless images. There is currently no debugger support
(you see the frames of the evaluator guts in the debugger), and in
general compiled code is a lot more developer-friendly.
Unlike CMUCL's interpreter SBCL's directly interprets the source code.
(CMUCL interprets the IR1 flow graph the compiler generates, IIRC.)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
.
- Prev by Date: Re: How do you read usenet news (c.l.l of course!)
- Next by Date: Re: (asdf:oos 'asdf:unload-op 'cl-spont)
- Previous by thread: nested presentations
- Next by thread: OT: Stern Environmental Review, a British Government Report published Online
- Index(es):
Relevant Pages
|
|