[Bug - Interpreter] binding captured in initialization form in parallel-binding form (let*, do*)

[Alessio Stalla]

Here is a bug I encountered (not real code):

(let* ((a (lambda () a))) (format t "~A ~A~%" a (funcall a)))

prints #<FUNCTION (LAMBDA ()) {53033E}> #<FUNCTION (LAMBDA ()) {53033E}>

----------

(do* ((a (lambda () a))) (nil) (format t "~A ~A~%" a (funcall a)))

prints
#<FUNCTION (LAMBDA ()) {284AC3}> #<FUNCTION (LAMBDA ()) {284AC3}>
#<FUNCTION (LAMBDA ()) {284AC3}> #<FUNCTION (LAMBDA ()) {284AC3}>
#<FUNCTION (LAMBDA ()) {284AC3}> #<FUNCTION (LAMBDA ()) {284AC3}>
...forever.

-----------

i.e. the binding "a" is captured by the initialization form, (lambda
() a). This only happens in interpreted code, compiled code correctly
signals an unbound-variable condition. And, the bug only appears for
operators that do parallel binding (let*, do*). let and do don't have
the bug.

Thanks to Erik for helping me correctly understand the bug ;)

Alessio

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

[Alessio Stalla]

I have committed a fix for the bug below. I have rerun the ANSI tests
and got no failures related to let* or do*, and I've made some
empirical tests myself, so I guess the fix is safe. Basically instead
of reusing the same environment for all the bindings and the body, an
extended environment is created for every binding.

Bye,
Alessio

On Sat, May 23, 2009 at 7:47 PM, Alessio Stalla <[hidden email]> wrote:

> Here is a bug I encountered (not real code):
>
> (let* ((a (lambda () a))) (format t "~A ~A~%" a (funcall a)))
>
> prints #<FUNCTION (LAMBDA ()) {53033E}> #<FUNCTION (LAMBDA ()) {53033E}>
>
> ----------
>
> (do* ((a (lambda () a))) (nil) (format t "~A ~A~%" a (funcall a)))
>
> prints
> #<FUNCTION (LAMBDA ()) {284AC3}> #<FUNCTION (LAMBDA ()) {284AC3}>
> #<FUNCTION (LAMBDA ()) {284AC3}> #<FUNCTION (LAMBDA ()) {284AC3}>
> #<FUNCTION (LAMBDA ()) {284AC3}> #<FUNCTION (LAMBDA ()) {284AC3}>
> ...forever.
>
> -----------
>
> i.e. the binding "a" is captured by the initialization form, (lambda
> () a). This only happens in interpreted code, compiled code correctly
> signals an unbound-variable condition. And, the bug only appears for
> operators that do parallel binding (let*, do*). let and do don't have
> the bug.
>
> Thanks to Erik for helping me correctly understand the bug ;)
>
> Alessio

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel