Is it accurate to say that variable capture can only occur in macros
that introduce local variable bindings? IOW, can capture occur in a
macro that has no LET operators or macro calls that expand to LET,
like DO?
Ari.
--
Elections only count as free and trials as fair if you can lose money
betting on the outcome.
···@lib.aero (K. Ari Krupnikov) writes:
> Is it accurate to say that variable capture can only occur in macros
> that introduce local variable bindings? IOW, can capture occur in a
> macro that has no LET operators or macro calls that expand to LET,
> like DO?
LET, PROGV, LAMBDA
You may be interested in other captures too, like block name capture,
or function name capture (FLET, LABEL).
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Pascal Bourguignon <····@mouse-potato.com> writes:
> ···@lib.aero (K. Ari Krupnikov) writes:
>
> > Is it accurate to say that variable capture can only occur in macros
> > that introduce local variable bindings? IOW, can capture occur in a
> > macro that has no LET operators or macro calls that expand to LET,
> > like DO?
>
> LET, PROGV, LAMBDA
I keep learning about new and new special operators in CL :=) Is PROGV
used much directly in code?
> You may be interested in other captures too, like block name capture,
> or function name capture (FLET, LABEL).
Indeed. Thank you for bringing these up, I hadn't thought of these
possibilities. I'm guessing that function name capture is conceptually
similar to LET-based variable capture? FLET and LABELS introduce new
bindings for symbols in a scope, similar to LET/LET*, only for
functions, and so should be prone to the same capture problems.
Ari.
--
Elections only count as free and trials as fair if you can lose money
betting on the outcome.
···@lib.aero (K. Ari Krupnikov) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> ···@lib.aero (K. Ari Krupnikov) writes:
>>
>> > Is it accurate to say that variable capture can only occur in macros
>> > that introduce local variable bindings? IOW, can capture occur in a
>> > macro that has no LET operators or macro calls that expand to LET,
>> > like DO?
>>
>> LET, PROGV, LAMBDA
>
> I keep learning about new and new special operators in CL :=) Is PROGV
> used much directly in code?
It's rather a low level special operator. It's used generally by code
generators.
>> You may be interested in other captures too, like block name capture,
>> or function name capture (FLET, LABEL).
>
> Indeed. Thank you for bringing these up, I hadn't thought of these
> possibilities. I'm guessing that function name capture is conceptually
> similar to LET-based variable capture? FLET and LABELS introduce new
> bindings for symbols in a scope, similar to LET/LET*, only for
> functions, and so should be prone to the same capture problems.
Yes.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
>> LET, PROGV, LAMBDA
> I keep learning about new and new special operators in CL :=) Is PROGV
> used much directly in code?
As far as I know, PROGV is used directly in exactly one situation:
writing interpreters for dynamically scoped languages. I believe it
was already present in Lisp 1.5, but I might be wrong.
The idiom looks something like (untested):
(defun my-eval (form)
(cond
((symbolp form) (symbol-value form))
((atom form) form)
;; dynamically scoped, LAMBDA doesn't build closures
((eq 'lambda (car form)) form)
(t (my-apply (car form)
(mapcar #'my-eval (cdr form))))))
(defun my-apply (f v)
(cond
...
((eq 'lambda (car f))
(progv (cadr f) v
(car (last (mapcar #'my-eval (cddr f))))))
...))
Correct me if I'm wrong, but PROGV is the only way in Common Lisp to
establish a dynamic binding when the names of the bound variables are
not known at compile-time (calls to EVAL let aside); so it is at least
theoretically necessary to have it in the language. OTOH, I've never
seen it actually used except in the idiom above.
Juliusz
Juliusz Chroboczek wrote:
> Correct me if I'm wrong, but PROGV is the only way in Common Lisp to
> establish a dynamic binding when the names of the bound variables are
> not known at compile-time (calls to EVAL let aside); so it is at least
> theoretically necessary to have it in the language. OTOH, I've never
> seen it actually used except in the idiom above.
I rely on PROGV in my implementation of ContextL. See
http://p-cos.net/documents/special-full.pdf for more details.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
···@lib.aero (K. Ari Krupnikov) writes:
> Is it accurate to say that variable capture can only occur in macros
> that introduce local variable bindings?
No. It can also occur in the opposite direction where the macro
attempts to expand to a symbol which has been locally rebound by the
code which uses the macro.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> ···@lib.aero (K. Ari Krupnikov) writes:
>
>>Is it accurate to say that variable capture can only occur in macros
>>that introduce local variable bindings?
>
> No. It can also occur in the opposite direction where the macro
> attempts to expand to a symbol which has been locally rebound by the
> code which uses the macro.
It can also occur in contexts that are completely unrelated to macros:
(let ((i 5))
...
(let ((i 42)) ; captures the outer i
...
... i ...))
This case can be as unintentional as the variable unintentionally
captured by macros.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
> > ···@lib.aero (K. Ari Krupnikov) writes:
> >
> >>Is it accurate to say that variable capture can only occur in macros
> >>that introduce local variable bindings?
> >
> > No. It can also occur in the opposite direction where the macro
> > attempts to expand to a symbol which has been locally rebound by the
> > code which uses the macro.
>
> It can also occur in contexts that are completely unrelated to macros:
>
> (let ((i 5))
> ...
> (let ((i 42)) ; captures the outer i
> ...
> ... i ...))
>
> This case can be as unintentional as the variable unintentionally
> captured by macros.
That's not variable capture, it's shadowing. If it's unintentional,
it's just a screwup by the programmer of that function. The conflict is
lexically apparent, so if he didn't notice it it probably means the
function is too long to keep track of what it's doing. It may also
indicate that he doesn't use good variable names.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
[variable capture]
>>It can also occur in contexts that are completely unrelated to macros:
>>
>>(let ((i 5))
>> ...
>> (let ((i 42)) ; captures the outer i
>> ...
>> ... i ...))
>>
>>This case can be as unintentional as the variable unintentionally
>>captured by macros.
>
> That's not variable capture, it's shadowing. If it's unintentional,
> it's just a screwup by the programmer of that function. The conflict is
> lexically apparent, so if he didn't notice it it probably means the
> function is too long to keep track of what it's doing.
This is slightly different if the shadowed variable is global, i.e., not
defined in the same function.
> It may also
> indicate that he doesn't use good variable names.
Right.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++