May 24-26 rough meeting notes

Jorge jorge at
Wed Jun 1 10:07:39 PDT 2011

On 28/05/2011, at 16:29, Brendan Eich wrote:
> On May 28, 2011, at 1:49 AM, Jorge wrote:
>> On 27/05/2011, at 12:24, Brendan Eich wrote:
>>> On May 27, 2011, at 2:36 AM, Jorge wrote:
>>>> Also, I wonder if in order to make blocks first class, do we need any new syntax ?
>>>> function f() {
>>>> a.forEach({ return 3 });
>>> The problem is that a block statement is ambiguous with an object initialiser. See in particular the "To enable unparenthesized ObjectLiteral expressions as bodies of arrow functions, without ambiguity with Block bodies, restrict LabelledStatement as follows..." section.
>> As labels are seldom used in JS, perhaps the easiest way to avoid ambiguities would be to forbid blocks from beginning with a label ?
>> Would it be too much (or too ugly) to require the programmer to disambiguate (only) in this corner case ?
>> A block:
>> { noLabelHere ... }
> We didn't talk about this change. It is yet another migration early-error to consider.

But it's not very usual to begin a block with a label.

> It's certainly simpler than a more powerful parsing algorithm than LR(1), 

If you 

1.- keep the familiar { block } syntax for first class blocks, and 
2.- use {|| ... } for shorter functions syntax and
3.- keep the (obligatory) parens as the call() operator

wouldn't we gain everything in the arrow syntax and block lambdas strawmen, except for paren-freeness ?

And, wouldn't that be easier for the current (proven) parsers, and pose almost zero risks in this respect ?

And, wouldn't that be in line the already known, much appreciated by many of us, current JS (and C) style ?

{ block }( call ) or {|| ... }( call )

foo bar baz ... wtf ?  foo(bar(baz)) ? foo(bar)(baz) ? foo(bar)(baz)() ? meh! This syntax introduces ambiguities !

Do David and Jeremy like it ? Good for them. Do JavaScripters like it ? The least we can say is that it's quite polemical : <>

> but we might want to cross that bridge anyway for arrow functions.


Arrow syntax is extraneous to JS developers. It's an unnecessary, radical style change. And ugly: there are JS developers that just *don't*like* it. 

So, why ? 

Paren-free(ness) is a fashion: foo bar baz, what's a function, who's calling who ? with which parameters ? Meh! Ambiguities.


> If we succeed there, we may not need such an incompatible restriction on labels.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list