Function Syntax

Brendan Eich brendan at mozilla.com
Thu May 12 10:55:58 PDT 2011


On May 11, 2011, at 4:01 PM, Allen Wirfs-Brock wrote:

> 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:
>> 
>>    array.map({|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.

Unlike functions taking function arguments, since null() and undefined() are inevitable errors. Do we really want to fork the funarg world in two?

When I rant against idealism and perfect being possible, I'm not just waxing philosophical. We live in a world of trade-offs. There is "better" but it rarely comes without something, however marginal or minority-share use-case, getting "worse".

Rubyists may cheer blocks in JS but we need to avoid making things strictly more complicated, in fork-the-subset-of-functions-taking-function-arguments terms, e.g.



>> 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.

Evidently not unless we model existing control flow statements as magic functions taking blocks. E.g., if is a function taking its condition, then outside the parenthesized (or paren-free if we do that!) condition, one or two blocks.


> Would people try to use such blocks as event handlers??

I suggested they would, because the syntax is so much shorter.


>  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.

Right, and a testing via code reflection onus.

Ruby is far from simple, btw. Check out

http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby

and the wikipedia page it references.

Looks like Proc.new but not lambda can return from its caller.


>> 3c. The use of {| (possibly with space in between) is an unambiguous extension, but formal parameters inside |...| delimiters creates a problem for http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values. 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.

User testing is hard, lots of confounders, hard to control. We'd need scale. We could try experimental annexes in ES.next for better function syntax, classes, other hard nuts to crack. Advise that if implemented they must track the annexes (or separate TRs, don't care). Only after some consensus emerges (if it does) do we standardize.

I don't see a quantitative way to decide, but this might be worth the overhead. Thoughts?

/be
> 
> Allen



More information about the es-discuss mailing list