Allen's lambda syntax proposal
Allen.Wirfs-Brock at microsoft.com
Fri Dec 5 12:49:07 PST 2008
>From: Brendan Eich [mailto:brendan at mozilla.com]
>The return hazard exists in Smalltalk too. What's different here that
>makes you choose differently? Of course, there are more choices than
>Tennent-to-the-max lambdas or-else classes-as-sugar.
The return hazard is not a significant problem in Smalltalk. This is probably because of the pervasive use of blocks (closures) for all control structures including the simplest if statements. Every Smalltalk programmer learns at the outset that the lexical occurrence of a ^ (ie, "return") anywhere in a method (even with within a nested block) means to return from that method. They generally learn this even before they learn that full semantics of [ ] (ie, lambda). So, there is really never any confusion about whether a ^ was intended to mean return from the block as opposed to return from a method. Occasionally, (actually pretty rarely) situations arise where it would be convenient to explicitly express returning from a block evaluation rather than the method. However, I've never seen a situations where that result couldn't be achieved by restructuring the method so the return case falls off the bottom. Various people have toyed with creating some sort of explicit local block return syntax for Smalltalk (for example ^^) but there are significant complications (since Smalltalk only has block based conditionals the local return would really be a situation of an inner block forcing a return from an outer block) and the need is quite limited. Finally, if restructuring the block doesn't solve the problem, Smalltalk's very flexible exception handling abstractions can probably be used to accomplish a similar result.
More information about the Es-discuss