On Sun, Oct 28, 2001 at 11:21:36AM +0300, Alexey Dejneka wrote:
> Alexey Dejneka <adejneka@...> writes:
> > The following program calls GENERIC-+ on 0.pre7.73!
> > (declaim (optimize (speed 3) (safety 0)
> > (debug 0) (space 0) (compilation-speed 0)))
> > (defun f+ (a b)
> > (declare (single-float a b))
> > (+ a b))
> EVAL, opposed to COMPILE-FILE, sets its own optimization policy.
What are you doing exactly?
If you get GENERIC-+ when you (LOAD (COMPILE-FILE "testcase.lisp")),
then it's a problem, but this is screwed up enough that I'd be
surprised that the system works.
Do you mean that this happens when you (LOAD "testcase.lisp")? In that
case, I think it's fairly reasonable behavior. LOAD calls EVAL on the
forms it reads, and EVAL is optimized for compilation speed, not
execution speed. In current sbcl-0.pre7, EVAL calls the compiler, but
in many implementations (like sbcl-0.6.13) you'd get an interpreted
F+, which'd do GENERIC-+ and be even slower besides.
I can see one possible problem with EVAL of DEFUN FOO creating a
really inefficient compiled function FOO:
* (LOAD "testcase.lisp")
* (COMPILED-FUNCTION-P #'F+)
* (COMPILE 'F+)
The COMPILE operation will do nothing, since the function is compiled
already; and thus you're left with a really inefficient FOO. This
isn't what you'd expect from an implementation with a real interpreter,
where instead you'd get an efficiently compiled #'F+.
Maybe this behavior is surprising enough that we should avoid it
somehow? I'm not sure how best to avoid it, though. And I expect it's
technically ANSI-compliant, since the standard explicitly allows
compiler-only implementations and I'm pretty sure EVAL is allowed to
ignore optimization policy.
William Harold Newman <william.newman@...>
God grant me serenity to accept the code I cannot change,
courage to change the code I can, and wisdom to know the difference.
-- Erik Naggum
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C