[Openmcl-devel] CCL bug?

[Gary Byers]

On Tue, 16 Mar 2010, Sudhir Shenoy wrote:

> Thanks for the pointer. It is clear now.
>
> Although I do not currently have this problem (libraries are my own so
> I can wrap the declaim declarations in an eval-when) what is the
> recommended procedure to ensure that there are no optimization side
> effects when loading a third-party library? Should one do the
> equivalent of getting the current optimization settings, loading the
> library and then setting the optimization settings back to what they
> were prior to the load?

I'd vote for asking the author/maintainer why they're writing code
that has load-time effects on optimization settings.

If the answer is "that wasn't intended, I'll change it", great.

If the answer is "but it works fine in ACME Common Lisp (tm), it's
only CCL that has a problem with this ...", well I don't think that
that's a correct answer, but it wouldn't be a surprising one.

One problem with the status quo is that CCL will process a toplevel

(declaim (optimize ...))

form by arranging for the OPTIMIZE declamation to be put into effect
at load time (and for it to have persistent effects on the global
environment).  I think that this behavior is consistent and correct,
but it apparently isn't expected.  If COMPILE-FILE generated some sort
of diagnostic:

; The OPTIMIZE declamation will have load-time effects which may
; not have been intended; use EVAL-WHEN to avoid this

then you might not have been surprised by those effects and may
have followed the message's advice; perhaps that'd also help to
get the authors of third-party libraries to think about the issue.

As confusing as this is, I think that CCL's behavior is intended to
be consistent and correct and that there are real advantages to that;
the load-time effects of a toplevel DECLAIM are well-defined even if
they aren't likely to be intended, and I really don't think that the
implementation should just guess at load time that you probably didn't
mean what you said.  (Expressing some skepticism about that at compile
time - like the suggested diagnostic above tries to - sounds like a
good idea at the moment.)


>
> This, of course, really makes a difference only when developing code
> in a live REPL where a CCL crash could take some partially developed
> code with it (BTW, this didn't actually happen to me because I was
> inside Emacs/SLIME but when raising hypothetical questions, I guess
> worst-case scenarios are admissible :-)
>
> Cheers
> Sudhir
>
> On Mar 16, 2010, at 1:51 PM, R. Matthew Emerson wrote:
>
>>
>> On Mar 16, 2010, at 12:34 AM, Sudhir Shenoy wrote:
>>
>>> You are right. I get
>>> ((SPEED 3) (SAFETY 0) (COMPILATION-SPEED 0) (SPACE 1) (DEBUG 1))
>>> in a fresh CCL instance. However, executing "ccl --no-init" gives me
>>> ((SPEED 1) (SAFETY 1) (COMPILATION-SPEED 1) (SPACE 1) (DEBUG 1))
>>>
>>> I am not setting the speed/safety settings explicitly in my ccl-
>>> init.lisp. However, some libraries that are autoloaded on startup are
>>> setting them.
>>>
>>> I guess it is correct to assume that I need to explicitly set (speed
>>> 1), (safety 1) after loading the libraries. I was under the
>>> impression
>>> that the compiler settings only affect the compilation units (files)
>>> and should reset automatically. However, looking at the Hyperspec
>>> now,
>>> it does say that it is unspecified if declaim-ed declarations persist
>>> after compilation ...
>>
>> It's probably not compile-time side-effects that are causing the
>> trouble, but load-time effects.
>>
>> See:
>> http://www.clozure.com/pipermail/openmcl-devel/2009-August/010168.html
>>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>