[Openmcl-devel] CCL bug?

[Robert Goldman]

On 3/16/10 Mar 16 -2:04 AM, Gary Byers wrote:
> 
> 
> 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.)

I believe that it might be helpful to peruse the ASDF development
mailing list.  I have a hazy memory of this issue coming up there.  In
particular, we were seeing the effect of DECLAIMs in Allegro Common Lisp
"bleed out" of their context and contaminate compilation (and loading?)
of downstream systems.

I don't know that we ever came up with a fully satisfactory answer.
IIRC, the problem is two fold:

1.  The spec isn't really as specific as could be about the scope of
optimization declarations and

2.  The spec doesn't allow portable access to the CURRENT value of
optimization settings, meaning there's no way to store, change, and
restore the values.

Best,
R