Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

Brendan Eich brendan at mozilla.com
Wed Jul 6 18:53:59 PDT 2011


On Jul 6, 2011, at 3:19 PM, Allen Wirfs-Brock wrote:

> So, a next step is to look at this in combination with other Harmony proposals.  In particular, the object literal extensions. 

Yes, I've been dividing and conquering ;-). Thanks for the followup.


> There is one pretty obvious ambiguity introduced by the methods property shorthand.
> 
> Keep mind that property names are permitted to be keywords.  So
> 
> let ambig1 = {function () {}};    //object with method named 'function' or 0 argument lambda that returns a function object?

Never the latter, anonymous function expressions are not produced by Statement.


> let ambig2 = {if (x) {5}};    //object with method named 'if' or 0 argument lambda that returns either 5 or undefined depending value of free variable x?

Quite.


> I don't think we want to loose the conciseness  of method property shorthand, but I we can resolve this one by restricting the property name to being an identifier rather than an identifierName in the method property shorthand.  Presumably if you really wanted to have a method property named function or if (or any other keyword) you could use a StringLiteral property name in the object literal:
> 
> let obj1 = {"function" () {}};    //object with method named 'function' 
> let obj2 = {"if" (x) {5}};    //object with method named 'if' 
> 
> However, are we going to have lookup issues with StringLiteral and NumericLiteral method property name? "if"(x) or 123() are syntactically valid call expressions so we have to see the { after the ) before we know it is an object literal and not a block lambda.

Lookahead issues, yes.


> Property value short hand is also a problem:
> 
> let x=2;
> let ambig3 = {x};  //is this an object literal equivalent to {x:x} or a 0 argument block lambda that returns the value of x?

That one is noted already in arrow function syntax.


> I don't see a easy way to resolve this one other than  dropping property value shorthand.  I'd be willing to sacrifice them in order to get block lambdas

Block lambdas as proposed don't have any ambiguities because they require empty || parameter lists for the zero-parameter case.


> I don't think the ! and ~ property attribute prefixes cause any ambiguity issues:
> 
> let obj3 = {~x: 5};
> let obj4= (!z(a,b,c,d) {}};
> 
> however, it does further increase the lookahead necessary be decide between an initial method property or an initial expression statement. This might be enough to reexamine the use of these attribute prefixes.

The lookahead requirement is a problem for LR(1) validation, which I'm skeptical we can or should step away from.


>  I still think we need attribute control functionality  in object literals but I think I would be willing to give up on them for the method property shorthand if that would help.  Essentially say that you have to use an old-fashioned property : property assignment if you want to specify non-default method attributes:
> 
> let obj4={!z: function(a,b,c,d) {}};

Could the attribute punctuators go after the property name instead of before?

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110706/01cf6105/attachment-0001.html>


More information about the es-discuss mailing list