Gee thanks a bunch for the great explanations about the FEXPR problem.
Now do you guys know what has been referred to as the "Funargs Problem"?
Any info here would be of interest also...
TIA
- DM
In article <·················@raytheon.com>,
Raytheon <········@azstarnet.com> wrote:
>Gee thanks a bunch for the great explanations about the FEXPR problem.
>Now do you guys know what has been referred to as the "Funargs Problem"?
>Any info here would be of interest also...
The funarg problem is a referential transparency problem with functional
arguments in dynamically-scoped Lisps. Consider:
(defun mapcar (fun list)
(loop for item in list
collect (funcall fun item)))
(defun add-to-list (item list)
"Return a list where each element is the sum of ITEM and the
corresponding element of LIST."
(mapcar #'(lambda (x) (+ item x)) list))
In a lexical Lisp, the lambda expression would be a closure, so its
references to ITEM would be the ITEM in ADD-TO-LIST's environment. But in
a dynamic Lisp, when the lambda expression is invoked by MAPCAR, it will be
evaluated in MAPCAR's environment, so ITEM will refer to the current
element of the list. As a result, ADD-TO-LIST will return a list where
each element is twice the corresponding element of the original list.
Changing the name of the parameter to ADD-TO-LIST or the iteration variable
in MAPCAR would fix this bug, but functions should not be sensitive to the
names of variables internal to other functions.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.
Barry,
I really appreciate your informed responses. I get the impression that you are an
"old-hand" at this stuff, quite possibly one of the Standard's Implementors. Is
that so?
Thanks again,
David McClain, Sr. Scientist
Raytheon Systems Co.
Tucson, AZ
Barry Margolin wrote:
> In article <·················@raytheon.com>,
> Raytheon <········@azstarnet.com> wrote:
> >Gee thanks a bunch for the great explanations about the FEXPR problem.
> >Now do you guys know what has been referred to as the "Funargs Problem"?
> >Any info here would be of interest also...
>
> The funarg problem is a referential transparency problem with functional
> arguments in dynamically-scoped Lisps. Consider:
>
> (defun mapcar (fun list)
> (loop for item in list
> collect (funcall fun item)))
>
> (defun add-to-list (item list)
> "Return a list where each element is the sum of ITEM and the
> corresponding element of LIST."
> (mapcar #'(lambda (x) (+ item x)) list))
>
> In a lexical Lisp, the lambda expression would be a closure, so its
> references to ITEM would be the ITEM in ADD-TO-LIST's environment. But in
> a dynamic Lisp, when the lambda expression is invoked by MAPCAR, it will be
> evaluated in MAPCAR's environment, so ITEM will refer to the current
> element of the list. As a result, ADD-TO-LIST will return a list where
> each element is twice the corresponding element of the original list.
> Changing the name of the parameter to ADD-TO-LIST or the iteration variable
> in MAPCAR would fix this bug, but functions should not be sensitive to the
> names of variables internal to other functions.
>
> --
> Barry Margolin, ······@genuity.net
> Genuity, Burlington, 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.
In article <·················@raytheon.com>,
Raytheon <········@azstarnet.com> wrote:
>Barry,
>
>I really appreciate your informed responses. I get the impression that you are an
>"old-hand" at this stuff, quite possibly one of the Standard's Implementors. Is
>that so?
I've been programming Lisp for about 20 years, and I was doing it
professionally for about 10 of those years (until about 6 years ago). I
was not involved in the original Common Lisp design (although I was at MIT
at the time and was friends with many of the people involved), but I was a
member of the X3J13 committee that later turned it into an ANSI standard.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.