(x) => {foo: bar}

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Re: (x) => {foo: bar}

Alexander Guinness

Can anyone explain what to expect as a result of the following expression?

var fn = () => ({ a, b } = { a: 0, b: 1 });


1. 

var fn = function () {
    var a = 0,
          b = 1;

    return { a: a, b: b };
};

or 

2. (traceur-compiler)

var fn = function () {
    var tmp;

    return (tmp = {a: 0, b: 1}, a = tmp.a, b = tmp.b, tmp);
};


There're global variables in the second case


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: (x) => {foo: bar}

Kevin Smith

var fn = () => ({ a, b } = { a: 0, b: 1 });

The expression `({ a, b } = { a: 0, b: 1 })` is a destructuring assignment.  If there are lexical bindings for `a` and `b` it will assign to those.  Otherwise, in strict mode it will fail with a ReferenceError.  In sloppy mode, it will assign to the global.

traceur is correct.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: (x) => {foo: bar}

Gary Guo
I found that even without shorthand, the object literal can still be ambiguous with block.

```js
()=>{
  method()
  {

  }
}

shall it be interpreted as
()=>({
  method(){
    // method body
  }
})

or 

()=>{
  method();
  {
    // block statement
  }
}
```

This is certainly an ambiguity that cannot be resolved by any transformation, or refinement of syntax. (so does the shorthand {x,y,z})

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Allen Wirfs-Brock
<base href="x-msg://751/">
On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:

I found that even without shorthand, the object literal can still be ambiguous with block.

Yes, but not in the context of a ConciseBody of an ArrowFunction.

The grammar for ConciseBody (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions ) ensures that there is no ambiguity. If a ConciseBody starts with a { then it must parse as either a well-formed bracketed FunctionBody or as a syntax error.

There is no guessing. { means statements follow rather than an expression.

allen 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
Allen Wirfs-Brock wrote:

> On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:
>
>> I found that even without shorthand, the object literal can still be
>> ambiguous with block.
>
> Yes, but not in the context of a ConciseBody of an ArrowFunction.
>
> The grammar for ConciseBody
> (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions 
> <http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-arrow-function-definitions>
> ) ensures that there is no ambiguity. If a ConciseBody starts with a {
> then it must parse as either a well-formed bracketed FunctionBody or
> as a syntax error.
>
> There is no guessing. { means statements follow rather than an expression.

Indeed. Perhaps Gary meant less formal ambiguity, as Caitlin did earlier
in thread -- in which case we could future-proof or perhaps just help
people by proscribing { L: 42 } from being parsed as a ConciseBody. I'm
curious to know what you think about this idea. It seems best done with
parametric productions, but I haven't worked it out yet.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Allen Wirfs-Brock

On Jan 7, 2015, at 1:23 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:
>>
>>> I found that even without shorthand, the object literal can still be ambiguous with block.
>>
>> Yes, but not in the context of a ConciseBody of an ArrowFunction.
>>
>> The grammar for ConciseBody (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions <http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-arrow-function-definitions> ) ensures that there is no ambiguity. If a ConciseBody starts with a { then it must parse as either a well-formed bracketed FunctionBody or as a syntax error.
>>
>> There is no guessing. { means statements follow rather than an expression.
>
> Indeed. Perhaps Gary meant less formal ambiguity, as Caitlin did earlier in thread -- in which case we could future-proof or perhaps just help people by proscribing { L: 42 } from being parsed as a ConciseBody. I'm curious to know what you think about this idea. It seems best done with parametric productions, but I haven't worked it out yet.

Certainly is plausible.  I suspect there might be a couple places in the ES grammar where we could replace lookahead restrictions with parameterization. I'm less sure whether there is a reason to prefer one over the other.

ObjectLiteral is already doing double duty covering ObjectAssignmentPattern.  so this would be even more complexity in this area of the grammar.

Finally, I'm sort of on the side that this may not be so good for programmers.  The rule, "if it starts with a { its a function body" is simple to teach and remember.  Adding "except if the first thing is a labeled expression statement" (or whatever) is more difficult to explain and remember.  More likely then not, all that many programmers would take away is "there are some special cases here that I don't really remember so I need to be really careful".  I'm not sure that is an improvement over the status quo.

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
Allen Wirfs-Brock wrote:
> ObjectLiteral is already doing double duty covering ObjectAssignmentPattern.  so this would be even more complexity in this area of the grammar.

Yeah, the complexity counter-argument is strong.

> Finally, I'm sort of on the side that this may not be so good for programmers.  The rule, "if it starts with a { its a function body" is simple to teach and remember.  Adding "except if the first thing is a labeled expression statement" (or whatever) is more difficult to explain and remember.  More likely then not, all that many programmers would take away is "there are some special cases here that I don't really remember so I need to be really careful".  I'm not sure that is an improvement over the status quo.

Me either, as noted up-thread. The option to prohibit a label at start
of body wouldn't commit us to doing block_vs_object_literal, though. It
would just carve out the future option. Still, no point in that work if
we think we will never take the option.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: (x) => {foo: bar}

Gary Guo
Even when we want to throw early errors for object-literal-like block, I consider my argument still valid.

```
()=>{
  method()
  {

  }
}
```
Should we throw an early error? Of course not, but it might be a potential error; out task is not to warn on object-literal-like block; instead, maybe simply we can just disallow improperly labelled statement in arrow function body.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Herby Vojčík
In reply to this post by Brendan Eich-2


Brendan Eich wrote:

> Mark Volkmann wrote:
>> My apologies. I meant to say that Traceur doesn't support returning a
>> literal object from an arrow function with syntax like this:
>>
>> let f = x => ({foo: bar});
>>
>> However, I just tested it again and it works fine. I could swear this
>> didn't work a few months ago. Maybe it was fixed recently. I'm happy!
>
> Cool -- you are supporting Caitlin's thesis that we can pedagogue around
> the footgun. I hope so.
>
> Still leaves
> http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
> as an option for ES7. Comments welcome.

A crazy idea:

(a, b) { body }
(a, b) => expr /* always expr context */

the only problem I quickly see is to distiguish (a) { body }, but IMHO
there is the same lookahead need for distiguishing (a) => something today.

> /be

Herby
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Herby Vojčík
In reply to this post by Marius Gundersen


Marius Gundersen wrote:

> I don't see how wellLabeledStatement will protect against object
> literals with shorthand properties, like (x, y, z) => {x, y, z}.
>
> The solution to the block vs object problem today is to wrap the object
> in parenthesis, but not the block. The only alternative that is easy for
> humans to understand and not ambiguous for machines is to wrap or prefix
> the block, but not the object, for example with do:
>
> x => do {
>    let a = 5;
>    return a*x;
> }

Yeah, this is good.

Even if do expression won't get in, if one could clearly tell the intent
(block vs. expression), it would make things easier to work with.

=> expr / => do block is less ambiguous then => expr / [nothing] block I
posted earlier.

>
> AFAIK do expressions are not in ES6, but might be in ES7.
>
> Marius Gundersen
>
> On 6 Jan 2015 19:42, "Brendan Eich" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Sorry, sent too soon.
>
>     Dean Landolt wrote:
>
>         If it's too late to properly vet a change which narrowly
>         excludes from arrow bodies any `LabeledStatement` that isn't a
>         `WellLabeledStatement`, would it be feasible to simply exclude
>         any `LabeledStatement` for now? I doubt there's much code in the
>         wild that would be affected by this change -- certainly not yet.
>         That'd buy plenty of time to add back proper support for
>         `WellLabeledStatement` arrow bodies in es7.
>
>
>     The ES6 grammar has not been refactored per my old strawman. It has
>     no WellLabeledStatement non-terminal.
>
>     For ES6, we would need another production parameter to FunctionBody,
>     FunctionStatementList, and StatementList (at least) by which to
>     restrict a ConciseBody : { FunctionBody } such that the FunctionBody
>     : FunctionStatementList (via FunctionStatementList :
>     StatementList[opt], StatementList StatementListItem, etc.) doesn't
>     start with a LabelledStatement.
>
>     Cc'ing Allen and Waldemar for their thoughts.
>
>     /be
>     _________________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.mozilla.org/__listinfo/es-discuss
>     <https://mail.mozilla.org/listinfo/es-discuss>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123