DECLAIM and PROCLAIM ??
fortunatus
hyperspec on DECLAIM:
"If a use of this macro appears as a top level form in a file being
processed by the file compiler, the proclamations are made at compile-
time."
"Also" compared to what? Compared to PROCLAIM? I don't find anything
under PROCLAIM that elucidates for me.
Does this mean that PROCLAIM works essentially at load time, whereas
DECLAIM works at compile time? Also under DECLAIM:
"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."
But heck, I'm using DECLAIM to specify things *to* the compiler - like
the speed vs. debug levels - and certainly they *do* have effect on
the compiled code, so effect *does* persist after the file has been
compiled.
I'm so confused!
fortunatus
> "If a use of this macro appears as a top level form in a file being
> processed by the file compiler, the proclamations are made at compile-
> time."
SHOULD BE:
"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."
(Emphasis mine.) That's the "also" that I was referring to...
Rob Warnock
+---------------
| What is the full difference between DECLAIM and PROCLAIM? From the
| hyperspec on DECLAIM:
|
| "If a use of this macro appears as a top level form in a file being
| processed by the file compiler, the proclamations are made at compile-
| time."
|
| "Also" compared to what? Compared to PROCLAIM?
No, compared to :LOAD-TOPLEVEL/:EXECUTE time.
+---------------
| I don't find anything under PROCLAIM that elucidates for me.
| Does this mean that PROCLAIM works essentially at load time,
| whereas DECLAIM works at compile time?
+---------------
Not quite. Since PROCLAIM is an ordinary function, it operates
*only* at :EXECUTE time, not even :LOAD-TOPLEVEL time!!
Even though it's non-normative, you may find it helpful to read
Issue PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
http://www.lispworks.com/documentation/HyperSpec/Issues/iss278.htm
http://www.lispworks.com/documentation/HyperSpec/Issues/iss278_w.htm
Note that the ugly proposed name DEFPROCLAIM *did* gtet renamed...
to DECLAIM! ;-}
It also might be helpful to look at what your CL implementation
expands DECLAIM to, e.g., here's CMUCL:
cmu> (macroexpand '(declaim (ftype function foo)))
(PROGN
(EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (PROCLAIM '(FTYPE FUNCTION FOO)))
(EVAL-WHEN (:COMPILE-TOPLEVEL) (C::%DECLAIM '(FTYPE FUNCTION FOO))))
T
cmu>
+---------------
| Also under DECLAIM:
|
| "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."
|
| But heck, I'm using DECLAIM to specify things *to* the compiler - like
| the speed vs. debug levels - and certainly they *do* have effect on
| the compiled code, so effect *does* persist after the file has been
| compiled.
+---------------
Ah, but *NOT* necessarily in the *compilation environment* itself!!
Consider: When you COMPILE-FILE some program that happens to contain
a (DECLAIM (OPTIMIZE (SPEED 3) (SAFETY 0))) at the top level, do you
*really* want those settings to persist *IN YOUR REPL* after the compile
finishes?!? Well, guess what: YOU DON'T KNOW WHETHER IT DOES OR NOT!!
The ANSI Standard doesn't promise you one way or the other.
[What your chosen implementation does is another matter, something
you might want to find out, in self-defense if nothing else... ;-} ;-} ]
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
fortunatus
> Not quite. Since PROCLAIM is an ordinary function, it operates
> *only* at :EXECUTE time, not even :LOAD-TOPLEVEL time!!
Good point! That sets up a lot. Let me check this scenario: I put
PROCLAIM for debug level in a file at top level, then I compile that
file. The PROCLAIM has no effect during the compile, thus no effect
on the resulting FASL. I load the FASL. Now the PROCLAIM takes
effect (it's executed during the load since at top level), but too
late with respect to the compile already done.
I change the PROCLAIM to DECLAIM and compile the file again. This
time the DECLAIM sets the debug level as the file compiles and that's
why I've been happy using DECLAIM.
-on the other hand-
I put neither PROCLAIM nor DECLAIM in the file. I'm at the REPL, and
I do a PROCLAIM for debug level. Now I compile my file, and since the
PROCLAIM is already executed, the debug level affects the FASL.
True?
Another scenario: In a file I DECLAIM a variable to hold only type
(INTEGER 0 255). I compile the file, and the compiler can optimize
code referencing that variable. Now I change the DECLAIM to
PROCLAIM. I compile the file, and the compiler does not optimize
because it knows nothing about values held in the variable.
Now I LOAD the FASL and the PROCLAIM takes effect. Too late for
optimizing code, but the run time activity could now do more detailed
type checking when that variable is referenced. If implemented.
True?
> Even though it's non-normative, you may find it helpful to read
> Issue PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
>
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss278.htm
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss278_w.htm
>
> Note that the ugly proposed name DEFPROCLAIM *did* gtet renamed...
> to DECLAIM! ;-}
>
> It also might be helpful to look at what your CL implementation
> expands DECLAIM to, e.g., here's CMUCL:
>
> cmu> (macroexpand '(declaim (ftype function foo)))
> (PROGN
> (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (PROCLAIM '(FTYPE FUNCTION FOO)))
> (EVAL-WHEN (:COMPILE-TOPLEVEL) (C::%DECLAIM '(FTYPE FUNCTION FOO))))
> T
> cmu>
I'll check it out - excellent pointers.
> Ah, but *NOT* necessarily in the *compilation environment* itself!!
>
> Consider: When you COMPILE-FILE some program that happens to contain
> a (DECLAIM (OPTIMIZE (SPEED 3) (SAFETY 0))) at the top level, do you
> *really* want those settings to persist *IN YOUR REPL* after the compile
> finishes?!? Well, guess what: YOU DON'T KNOW WHETHER IT DOES OR NOT!!
> The ANSI Standard doesn't promise you one way or the other.
Also clears up. Thanks so much!
fortunatus
> Issue PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
>
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss278.htm
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss278_w.htm
>
> Note that the ugly proposed name DEFPROCLAIM *did* gtet renamed...
> to DECLAIM! ;-}
In the above I found the following suggestion, which I don't think was
taken - it would help newbies like me a lot:
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation,
or use the macro DEFPROCLAIM.
(I've only been hacking LISP 6 1/2 years so far...)
Pascal J. Bourguignon
> On Sep 28, 10:11 pm, r...@rpw3.org (Rob Warnock) wrote:
>
>> Not quite. Since PROCLAIM is an ordinary function, it operates
>> *only* at :EXECUTE time, not even :LOAD-TOPLEVEL time!!
>
> Good point! That sets up a lot. Let me check this scenario: I put
> PROCLAIM for debug level in a file at top level, then I compile that
> file. The PROCLAIM has no effect during the compile, thus no effect
> on the resulting FASL. I load the FASL. Now the PROCLAIM takes
> effect (it's executed during the load since at top level), but too
> late with respect to the compile already done.
>
> I change the PROCLAIM to DECLAIM and compile the file again. This
> time the DECLAIM sets the debug level as the file compiles and that's
> why I've been happy using DECLAIM.
>
> -on the other hand-
>
> I put neither PROCLAIM nor DECLAIM in the file. I'm at the REPL, and
> I do a PROCLAIM for debug level. Now I compile my file, and since the
> PROCLAIM is already executed, the debug level affects the FASL.
>
> True?
Correct.
> Another scenario: In a file I DECLAIM a variable to hold only type
> (INTEGER 0 255). I compile the file, and the compiler can optimize
> code referencing that variable. Now I change the DECLAIM to
> PROCLAIM. I compile the file, and the compiler does not optimize
> because it knows nothing about values held in the variable.
Correct.
> Now I LOAD the FASL and the PROCLAIM takes effect. Too late for
> optimizing code, but the run time activity could now do more detailed
> type checking when that variable is referenced. If implemented.
>
> True?
Correct.
--
__Pascal Bourguignon__ http://www.informatimago.com/
fortunatus
Thomas A. Russ
> On Sep 28, 10:11滋pm, r...@rpw3.org (Rob Warnock) wrote:
>
> > Not quite. Since PROCLAIM is an ordinary function, it operates
> > *only* at :EXECUTE time, not even :LOAD-TOPLEVEL time!!
>
> Good point! That sets up a lot.
As a practical matter, you would almost always want to use DECLAIM, now
that it exists.
The only exception would be if you were constructing code at run-time
and need to have a function that you can call with arguments that you
determine at run time. Since this is uncommon, you can generally not
really consider using PROCLAIM in your everyday coding.
--
Thomas A. Russ, USC/Information Sciences Institute
Tim Bradshaw
> The only exception would be if you were constructing code at run-time
> and need to have a function that you can call with arguments that you
> determine at run time.
Another exception would be implementing DECLAIM, of course :-)
Thomas A. Russ
Tim Bradshaw
> Presumably that is done once by the implementor.
It is *now*...
(But I was joking)