[Openmcl-devel] tail calls in 1.3 IDE?

[Gary Byers]

Compile-time side-effects from DECLAIM (especially those that affect
OPTIMIZE settings) generally don't persist after the file's been
compiled in CCL.  IIRC, this seemed to be true of most/all other
implementations as of the last time I checked, though as Tim notes a
conforming implementation -could- allow those changes to persist
longer than that.

There seems to be a lot more variance in how implementations
handle load-time effects, and it seems that in many implementations
changes to OPTIMIZE settings (at least) do not persist after the
containing file's been LOADed.  CCL used to do this several years
ago, but I can't see anything in the spec that justifies limiting
the extent of those effects (and can see quite a bit that seems to
disallow it), and in CCL changes to OPTIMIZE settings that occur
at load time are persistent.

However interesting the load-time behavior is or isn't, in most
cases (I assume), someone saying (DECLAIM (OPTIMIZE ...)) expects
those optimization settings to take effect at compile time (and
influence at least the compilation of the containing file) and
doesn't really expect the optimize settings to be put into effect
when the fasl file is subsequently loaded.  For that reason alone,
using the idiom:

(eval-when (:compile-toplevel)
   (declaim (optimize ...)))

is generally preferable to letting the declamation have any load-time
effect in any implementation (both because implementations differ in
their handling of those effects and because it's very likely that
no load-time effects were intended.)

It's true that CL doesn't guarantee that an implementation will
limit the extent of changes to OPTIMIZE settings to that of
the current call to COMPILE-FILE, but I believe that in practice
all implementations do (or did as of a few years ago.)

I think that there's a lot of widely-available CL code out there
that (unintentionally) allows (DECLAIM (OPTIMIZE ...)) to have
load-time effects, and I think that implementations that try
to limit the extent of those load-time effects likely do so
on the assumption that their introduction was accidental.  (That
was certainly the rationale when CCL behaved that way.)

The rationale for changing to the current behavior is the belief
that the old behavior isn't correct (and among other things that
loading "globally-and-persistently-change-optimize-settings.fasl"
should have the effect of globally and persistently changing
optimize settings, even if that's an obscure thing to do.)  In
CCL, it's also true that loading "unintentionally-globally-and-persistently-
change-optimize-settings.fasl" can have the same effect, even if
the latter file is actually named "otherwise-useful-cl-utility.fasl"
or (in this case) "part-of-easygui.fasl".

[I used to remember the difference between "effect" and "affect",
but as I was writing this it occurred to me that I was mostly
guessing ...]

On Fri, 14 Aug 2009, Tim Bradshaw wrote:

> On 14 Aug 2009, at 16:08, Arthur W Cater wrote:
>
>> However, I suspect that wrapping in eval-when as suggested will
>> still affect files subsequently
>> compiled in the same session, at least.
>
> That's right: "If a use of this macro appears as a top level form in a
> file being processed by the file compiler, the proclamations are also
> made at compile-time. As with other defining macros, it is unspecified
> whether or not the compile-time side-effects of a declaim persist
> after the file has been compiled."
>
> --tim
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>