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