I'm curious about the reason why a (DECLARE ...) clause is not valid after a PROGN, but it is after any form that produces bindings, like PROG, PROG*, LET, DEFUN, etc, etc.
In particular I tried to write a macro that expanded to this:
(progn (declare (optimize (debug 2))) ..... ) ;; body of code
This is rejected, but the following works okay,
(let () (declare (optimize (debug 2))) ....) ;; body of code
Not complaining, mind you... I realize a lot of very great talent applied their best thinking to this language. I'm just curious about why binding influences are needed in preparation for a (DECLARE (OPTIMIZE ...))
* "David McClain" <bar...@qwest.net> | I'm curious about the reason why a (DECLARE ...) clause is not valid after a | PROGN, but it is after any form that produces bindings, like PROG, PROG*, | LET, DEFUN, etc, etc.
Because you should use the special operator locally to do this, not progn.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming
>I'm curious about the reason why a (DECLARE ...) clause is not valid after a >PROGN, but it is after any form that produces bindings, like PROG, PROG*, >LET, DEFUN, etc, etc.
The point of the DECLARE in the body of these things is to make a declaration about one of the variables that they introduce. Since PROGN doesn't introduce any new variables, why does it need to allow declarations?
>In particular I tried to write a macro that expanded to this:
>(progn > (declare (optimize (debug 2))) > ..... ) ;; body of code
Isn't this what LOCALLY is for?
(locally (declare (optimize (debug 2))) ...)
I suppose we probably could have done without LOCALLY, and simply stated that PROGN allows declarations at the beginning and their scope is the PROGN form. However, PROGN has the nice associative property that:
(progn a b c ... (progn d e f ...))
is equivalent to:
(progn a b c ... d e f ...)
This equivalence breaks down if you allow special cases in certain positions.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> I'm curious about the reason why a (DECLARE ...) clause is not valid after a > PROGN, but it is after any form that produces bindings, like PROG, PROG*, > LET, DEFUN, etc, etc.
> In particular I tried to write a macro that expanded to this:
> (progn > (declare (optimize (debug 2))) > ..... ) ;; body of code
> This is rejected, but the following works okay,
> (let () > (declare (optimize (debug 2))) > ....) ;; body of code
> Not complaining, mind you... I realize a lot of very great talent applied > their best thinking to this language. I'm just curious about why binding > influences are needed in preparation for a (DECLARE (OPTIMIZE ...))
You've got causality backward. It isn't that binding influences are needed in pre of a DECLARE, but rather that because there are bindings being done, DECLARE must be made available to control things like the possibility of SPECIAL and DYNAMIC-EXTENT. In the case of PROGN, nothing forces this need, so DECLARE isn't required to be handled there.
But also, a practical implication of what you want is that implicit progns would also be affected. This would mean that every user macro that had a progn or implicit progn would have to manage declaration processing. In general, that's quite a pain. Often the declarations need to get moved to a different place in an expansion than the body code. Since progns and implicit progns occur a lot, the job of writing macros would be massively complicated. LOCALLY is just a PROGN that allows declarations [though it's usually implemented as a null LET, since LET has to do declaration processing anyway].
Yes, very helpful indeed from all of the respondents. I was completely unaware of LOCALLY and you have all taught me something new. For that I am quite grateful to you all!
