I've been looking at the evaluator branch again. Juho has reported
that it gives a significant speed advantage on ACL2, which seems to
be frobbing DEFUNs and then calling EVAL on them.
I've got my own tree with a forward port of evaluator-again-branch to
mainline, which was mainly a matter of removing instance-lambda.
Right now, the remaining issues that I can see are:
* sb-cltl2 tests fail, because forms like (locally (declare (optimize
speed)) (sb-cltl2-tests::dinfo speed)) don't do the right thing
(where dinfo is a macro which expands into the value of that
optimization declaration at compile time). It would probably be best
to pick up on optimize declarations, just for consistency's sake.
* As a small matter, the evaluator needs to be handling COMPILER-
ERRORs and converting them to regular ERRORs just like the old
* Nothing pretty is done with backtraces: if you find an error in an
evaluated function, you will see all the steps that EVAL took to get
to that error in the backtrace. I'm unsure as to whether we really
want to munge the backtrace to look pretty, though. I don't think
Allegro does anything like that, just as a point of comparison. We
might be able to prettify the backtrace some already just by inlining
the EVAL-FOO helper functions into %EVAL.
* No support for stepping evaluated functions. I don't think this is
terribly hard to do.
* No support for calling COMPILE on generic functions or methods as
far as I know.
The first two are things I intend to fix soon. The latter three will
take some time, and I'm not sure about whether backtraces are required.
I'm wondering what the consensus for merge criteria for the evaluator
branch is. If all of these should be done before a merge happens,
then it makes sense to make (another) forward-port branch and
hopefully enlist some people to work on this. If not, then perhaps I
can commit this soon.