On Tue, Jul 16, 2002 at 05:09:45PM +0100, Christophe Rhodes wrote:
> Now that Dan's nearly reimplemented stack exhaustion checking, I'd like
> to solicit opinions on what the REPL ought to do with respect to
> compilation optimization policy.
> Currently, if you do at the REPL:
> * (foo 3)
> what actually happens is (more or less):
> * (funcall (compile nil
> (lambda () (declare (optimize (safety 3)
> (compilation-speed 2)
> (speed 1)
> (debug 1)
> (space 1)))
> (foo 3))))
> [ I apologize in advance for the appalling indentation. ]
> The problem that I have experience with this is that it interacts badly
> with PROCLAIM/DECLAIM. A PROCLAIM at the REPL
> * (proclaim '(optimize (speed 3) (safety 1)))
> will have no effect on, say,
> * (defun fast-function (x) ...)
> because the optimize qualities are hard-coded in src/code/eval.lisp. Of
> course, I can do
> * (defun fast-function (x)
> (declare (optimize (speed 3) (safety 1)))
> and this will work as expected, but this is not terribly convenient when
> interacting with lisp from an emacs buffer, say, when doing incremental
> development ("why is he incrementally developing after optimization, I
> hear you all cry").
> So, what I would like is that the default state of the optimization
> qualities in src/code/eval.lisp be set to whatever seems sensible (like
> the above, maybe with slightly higher DEBUG), but that they be removed
> from the generated lambda so that PROCLAIM and friends can work at the
> Does this make sense? Any thoughts?
I'm not quite sure what you mean here.
The way your proposal is phrased, it sounds to me as though eval.lisp
would still have its own optimization policy values. But if eval.lisp
doesn't put them into the LAMBDA, then what would it do with them?
Do you mean that eval.lisp shouldn't have its own versions of
optimization policy at all, so that the PROCLAIMed-at-toplevel values
would always apply to "interpreted" code (when EVAL punts and asks
COMPILE for help)? I think that would be a reasonable replacement for
the current behavior, since your example shows the current behavior
can be annoyingly surprising and inflexible.
Or perhaps you mean that eval.lisp should do some more-complicated
defaulting thing, e.g. inserting its preferred policy only when the
user hasn't explicitly declared his own policy preference? I'm not
sure what to think about this without understanding better how
eval.lisp would make its opinions known to the compiler.
William Harold Newman <william.newman@...>
"That's when the megagod Reality showed up."
-- Jessica Mulligan <http://www.skotos.net/articles/BTH_27.shtml>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C