Function Syntax

Allen Wirfs-Brock allen at
Wed May 11 16:01:58 PDT 2011

On May 11, 2011, at 9:53 AM, Brendan Eich wrote:

> ...
> 3. Blocks as implicitly quoted code could be like zero-argument lambdas, with break, continue, return, |this|, and |arguments| referred to any outer function or loop/switch statement. This suggests something like the Ruby-ish syntax Isaac sketched recently, mooted by various people in the past:
>{|x| x * 2 }) // YAY!
> Problems:
> 3a. Basis case is {}, an object initialiser. Patchable by requiring {||}, but ugh.

In practice, such null blocks would probably seldom occur.  Particularly, if the convention was for functions taking "block" arguments to treat undefined/null as the do nothing block.

> 3b. The objection raised repeatedly when we discussed lambdas here, that return unwinding an outer function, or throwing an error if the outer function call has already returned, is as big a hazard and source of confusion as -- or bigger than! -- any completion-return downside.

I can't speak to Ruby usage, but such errors are a rare occurrence in Smalltalk where such blocks are the only way to express control abstractions.   Don't know if the same would be true for JS. Would people try to use such blocks as event handlers??  The actual runtime test that is needed to test for already returned can be pretty cheap.  It would probably be possible to add a way to test whether a block contains any non-local exists.  Any code that wants to make sure it doesn't see should errors could test their block arguments before stashing them way.  Of course, that just replace on error with a different earlier error.

> 3c. The use of {| (possibly with space in between) is an unambiguous extension, but formal parameters inside |...| delimiters creates a problem for We would need the default value expression to be parenthesized if its precedence were | (bitwise-or) or looser.
> Other than these, AFAICT blocks as lambdas offering shorter function-like syntax are pretty good. Should we reconsider them?

I think this is an area that really cries out for an experimental design and implementation.


More information about the es-discuss mailing list