May 24-26 rough meeting notes

Jorge jorge at jorgechamorro.com
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 http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes 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 : <https://github.com/rails/rails/commit/9f09aeb8273177fc2d09ebdafcc76ee8eb56fe33>

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

<fwiw>

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.

</fwiw>

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

-1
-- 
Jorge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110601/19bbee0a/attachment.html>


More information about the es-discuss mailing list