On Sun, 17 Jan 2010, [email protected] wrote:
> Levente and Lukas,
>
> You both agree that this is not a bug, them we have to ascertain that
> 'average Smalltalker' will understand that using closures in Pharo changes
> the Smalltalk language definition.
The semantics change in various ways. The trivial example that everyone
knows is this:
factorial := [ :n |
n > 1
ifTrue: [ n * (factorial value: n - 1) ]
ifFalse: [ 1 ] ].
factorial value: 10.
Without closures you get an error, with closures you get the expected
result.
Another significant change is the existence of local variables in blocks.
Without closures blocks don't have local variables, with closures they do:
b := [ :p |
| t |
t ifNil: [ t := p ] ].
{ b value: 1. b value: 2 }
In a non-closure image you get #(1 1) as result, because t is not a block
local variable even if it looks like one. In a closure image you get #(1 2)
because t is a block local variable.
Levente
>
>
>
> Em 17/01/2010 06:57, Lukas Renggli < [email protected] > escreveu:
>
>
>> I believe this is a bug.
>
> That's the correct behavior. This is exactly how closures should
> behave. The variable declaration is outside the block you store thus
> one variable slot is shared among multiple block definitions inside.
> See ClosureTests for more examples of that behavior.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
