May 24-26 rough meeting notes

Brendan Eich brendan at mozilla.com
Sat May 28 07:29:37 PDT 2011


We didn't talk about this change. It is yet another migration early-error to consider. It's certainly simpler than a more powerful parsing algorithm than LR(1), but we might want to cross that bridge anyway for arrow functions. If we succeed there, we may not need such an incompatible restriction on labels.

/be

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 ?
> 
> An object:
> { label: expression }
> 
> An error:
> { label: return 5 }
> 
> A block:
> { ;  label: expression }
> 
> A block:
> { noLabelHere ... }
> -- 
> Jorge.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list