Re: [Sbcl-devel] *EVALUATOR-MODE* :interpret and EVAL

[Juho S. <js...@ik...>]

On Sun, Mar 7, 2010 at 11:24 AM, Tobias C. Rittweiler <tc...@fr...>wrote:

>
> What is the reason that EVAL does not use the interpreter now that
> it's back there?
>

Because the interpreter sucks in the general case, and is really only meant
for a few special cases. It's incredibly slow, interpreted code is
impossible to debug, will bypass  any static error checking, etc. We'd be
doing our users a disservice by downgrading them from a compiled eval to the
interpreter.

At the very least we'd have to ensure that in many of the places where sbcl
currently calls eval we'd continue using :compile by default. It'd be
absolutely unacceptable to have code entered at the repl or loaded from
source rather than fasls be orders of magnitude slower by default. And then
we'd need further kludges to ensure that users who know what they're doing
and really *want* load-from-source to use the interpreter still have a way
of achieving that.

I'd really like if I can use C-M-x to undo typos when working on
> SBCL's compiler itself. Introducing a swank-backend REAL-EVAL function
> seems like a kludge to taper over an SBCL pecularity.
>

Sure, that's one of the rare cases where the interpreter is useful, and I do
the same thing. But that just means that you can set the default evaluator
mode to :interpret in your own .sbclrc, there's no need to change the global
default.

(Or better yet, just set *evaluator-mode* iff you do end up hosing the
image. There's ways to do that even with a broken compiler, like (set
'*evaluator-mode* :interpret))

-- 
Juho Snellman