[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: declaration pervasiveness.
- To: gls@THINK.ARPA
- Subject: Re: declaration pervasiveness.
- From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
- Date: Thu 13 Jun 85 15:44:59-EDT
- Cc: common-lisp@SU-AI.ARPA, jk@SU-AI.ARPA
- In-reply-to: Message from "Guy Steele <gls@THINK.ARPA>" of Thu 13 Jun 85 14:39:33-EDT
The notinline declaration does not apply to the call to the (bar m m) version.
The description of notinline specifically notes that lexical scoping is observed
regarding the references to function names occurring in the declaration.
So the declaration (notinline f) refers to the function named f that is visible
at that point, namely the (* m m) version. The declaration is pervasive in that
it affects all *calls* to that specific f (not *bindings* of other functions
also named f) in the body of the construct. The call to the (bar m m) version
is not a call to the f referred to by the notinline declaration, but to some
other f, and so is not affected by that declaration.
Ok. Thats sounds reasonable. But what's the difference between a
pervasive and a non-pervasive declaration then? Your description
would fit a type declaration also, which the manual says is not
pervasive. As I read it the only difference is that in addition to
what you say above, the declaration of notinline, since it is
pervasive (page 155), also applies to calls to that specific f within the local
function definitions of an FLET or LABELS (which are outside the
body). By your lexical scoping argument this only affects LABELS
as that particular f is not visible in the FLET function definitions.
Could you comment on whether these declarations are even legal in the
body of an FLET, LABELS or MACROLET since pages 113 and 154 seem to
On random typography: in the table at the top of page 154, do*
preceeds do whereas let* and prog* come after let and prog