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._______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
