A Lisper asks, "Am I supposed to like Smalltalk?"
Stéphane Rollandin
lecteur at zogotounga.net
Wed May 17 10:12:08 UTC 2006
Andreas Raab wrote:
>
> Out of curiosity, can you explain to me why using:
>
> f := Lambda x + Lambda y.
> f <~~ {3. 4}
>
> would be substantially different from
>
> f := [:x :y| x + y].
> f value: 3 value: 4.
>
in this precise example (with numeric arguments) the behavior is not
different: actually the former uses the latest internally as its
so-called "compiled form".
but now
f <~~ {3 . f}
is not at all the same as the block version
f value: 3 value: f
(which opens the debugger)
you can check that
(f <~~ {3 . f}) = (3 + (Lambda x + Lambda y))
returns true.
it also is different if you have
x := Lambda x.
y := Lambda y.
f := x + y.
g := x * y.
because you can then directly do
(g+f) <~~ {3.4}
while with blocks you would have to do
f := [:x :y| x + y]
g := [:x :y| x * y].
gplusf := [:x :y| (f value:x value: y) + (g value:x value: y)]
the printString is much clearer also:
(g+f) printString
is
'((<x> * <y>) + (<x> + <y>))'
while
gplusf printString
is
'[] in UndefinedObject>>DoIt {[:x :y | (f value: x value: y) + (g
value: x value: y)]}'
(I did this in a workspace)
> I'm in particular curious about your claim this is
> "now" possible which seems to imply that there is something
> LambdaMessageSend does that blocks/closures for some reason can't
> represent properly.
in short, LambdaMessageSend implements closures out of nested
MessageSends. compared to blocks it is another, completely different way
to do functional programming in Smalltalk
example:
f := Lambda x + Lambda y.
g := f <~~ {15 . Lambda z sqrt}.
g printString is '(15 + (<z> sqrt))'
and indeed
g <~ 100 return 25.0
g asBlock (compilation) returns the block [:t1 | 15 + t1 sqrt] allright
how do you do this with blocks ?
regards,
Stef
More information about the Squeak-dev
mailing list
|