Re: Is let let = 1 a valid statement?

[Eric Suen]

Thanks, maybe should add es6draft to https://github.com/addyosmani/es6-tools

I don't even know this exists, and wiki is down too...

On Fri, Nov 13, 2015 at 6:44 PM, Till Schneidereit
<t...@tillschneidereit.net> wrote:
> On Fri, Nov 13, 2015 at 8:18 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>>
>> My bad, I mixd it with esprima, on Chrome and Firefox in loose mode, let
>> declaration is not support.
>> so it's syntax error, in esprima, let let = 1 is invalid, but let private
>> = 1 is valid.
>
>
> When testing things like this, I would recommend testing against the latest
> development versions of browsers, i.e. Chrome Canary and Firefox Nightly. At
> least in the latter, let is supported in strict and non-strict mode.
>
> Also, take a look at es6draft, which strives (very successfully) to be a
> highly compliant implementation of the entire spec:
> https://github.com/anba/es6draft



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is let let = 1 a valid statement?

[Eric Suen]

My bad, I mixd it with esprima, on Chrome and Firefox in loose mode, let 
declaration is not support.
so it's syntax error, in esprima, let let = 1 is invalid, but let private = 
1 is valid.


"Eric Suen" 
news:cadsmrny42euuws4akzw4_2qsbng+m_t+ke-y8mh1tauag9z...@mail.gmail.com...


In both Chrome and Firefox,

let FutureReservedWord = expr is invalid, but const | var
FutureReservedWord = expr is valid, is this defined in ES 6 or
historical reason?

let/const both are LexicalDeclaration, why behave differently?

--

Spket IDE - Development Tool for RIA.

http://www.spket.com 



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Is let let = 1 a valid statement?

[Eric Suen]

In both Chrome and Firefox,

let FutureReservedWord = expr is invalid, but const | var
FutureReservedWord = expr is valid, is this defined in ES 6 or
historical reason?

let/const both are LexicalDeclaration, why behave differently?

-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Eric Suen]

In Spec it's clear that escaped reservedWords is not Identifier nor ReservedWord

In 
https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
you said it's keywords...
I said in Jave/C# escaped keywords is keywords, you said JavaScript is
not Java nor C#...

In https://code.google.com/p/google-caja/wiki/SecurityAdvisory20131121
"JavaScript parsers differ on whether they interpret escaped sequences
of letters spelling a reserved word, such as "de\u006Cete", as an
identifier or a reserved word." that may cause issue.

Till today still none Engine/Tool parse it correctly, Chrome/babel
treat it as Identifier, IE 11 and Firefox 42.0 and esprima treat it as
keywords.

It's confirm that escaped reservedWords is not Identifier. Can I have
a final conclusion is it keywords or not?

On Tue, Nov 10, 2015 at 1:05 AM, Allen Wirfs-Brock
 wrote:
>
> On Nov 9, 2015, at 6:55 AM, Andreas Rossberg  wrote:
>
> Allen, what was the motivation for allowing random escapes in
> identifiers but not in keywords? AFAICS, it would be simpler and more
> consistent to allow them anywhere and render "escape normalisation" a
> uniform prepass before tokenisation. IIUC, that's what other languages
> do. The current ES rules are far from ideal, and require jumping
> through extra hoops, in particular, to handle context-dependent
> keywords like `yield`.
>
> /Andreas
>
>
> see:
>
> Here are some references:
> https://github.com/tc39/tc39-notes/blob/master/es6/2013-11/nov-20.md#42-clarification-of-the-interaction-of-unicode-escapes-and-identification-syntax
> https://bugs.ecmascript.org/show_bug.cgi?id=277
> https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
> https://esdiscuss.org/topic/this-vs-thi-u0073
>
> there are many others, and also there were earlier TC39 meeting discussions
> that I didn’t find in my quick search.
>
> It’s a usability vs. implementor convience trade-off.  the TC39 was to go
> with usability (and in particular readability).
>
> (Also, my recollection is that in some TC39 discussions (that I didn’t find
> in my search) there were security concerns raised WRT allowing unicode
> escapes in keywords. Probably concerns about code injection filters not
> recognizing escaped keywords)
>
> In ES6 (and I believe that Waldemar would claim in previous editions)
> unicode escapes cannot be handled with such a prepass. Essentially, escaped
> and non-escaped IdentifierName characters are only equated when doing
> identifier binding or property name lookups. It’s probably a misperception
> of the lexical grammar and static semantics that leads some implementors
> down the path of thinking that  such a preps is reasonable.
>
> Regarding `yield`, if it is written containing unicode escapes it is never a
> contextual keyword.
>
> BTW, personally I I would be just fine with never allowing unicode escapes
> within IdentiferName. But that would be a web breaking change.
>
> Allen
>
>



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Is \u006eew a valid Identifier?

[Eric Suen]

"The ReservedWord definitions are specified as literal sequences of
specific SourceCharacter elements. A code point in a ReservedWord
cannot be expressed by a \ UnicodeEscapeSequence." - what does it
mean?

The following code is valid in Chrome, but invalid in firefox and IE.

var \u006eew = 1; // \u006e = 'n'

and valid in Babel/Traceur, invalid in typescript/esprima...

-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Eric Suen]

So escaped ReservedWords are not valid as ReservedWords nor
Identifier, what is it then?

And in export { IdentifierName }, why it's IdentifierName not
Identifier. since IdentifierName only valid as Property in
ObjectLiteral or Method in Class, is there any way to define
ReservedWords as local name?

'get'/'set' is ContextuallyReservedIdentifier, maybe that's the reason?


On Sat, Nov 7, 2015 at 11:32 PM, Caitlin Potter <caitpotte...@gmail.com> wrote:
> That it works in Chrome is a bug, which will hopefully be fixed by Monday or 
> Tuesday!
>
> Per http://tc39.github.io/ecma262/#sec-keywords, “new” is a Keyword, which 
> makes it a ReservedWord.
>
> Per 
> http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors, 
> under the
> “Identifier: IdentifierName but not ReservedWord” section, the second early 
> error applies here. This applies to
> `new`, which is always a reserved word. So whenever an Identifier is 
> expected, if it contains UnicodeEscapeSequences which result in the same 
> StringValue as a ReservedWord, it’s an error.
>
> The spec is similarly explicit in saying that escaped ReservedWords are not 
> valid as ReservedWords. Browsers behave differently here (for instance, 
> http://jsfiddle.net/jd51pqae/ <<< at the time of this writing Webkit Nightly 
> prints the text, while other browsers SyntaxError. in Chromes case, this is 
> because it’s tokenized as an Identifier, so the second Identifier “f” is 
> unexpected when parsing a MemberExpression. SpiderMonkey is doing a nice job 
> of reporting clean errors for this kind of thing, that are easier to 
> understand.
>
> There are some odd points though:
>
> 1. ReservedWord restrictions never apply to `get` or `set`, even in 
> ObjectLiterals (though currently Chrome fails to treat `g\u{65}t` or 
> `s\u{65}t` as an accessor prefix, this is a bug).
>
> 2. In the case of “new.target”, it’s technically legal to write 
> `new.t\u{61}rget`, but this mostly just seems like an oversight in the spec.
>
>> On Nov 7, 2015, at 9:50 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>>
>> "The ReservedWord definitions are specified as literal sequences of
>> specific SourceCharacter elements. A code point in a ReservedWord
>> cannot be expressed by a \ UnicodeEscapeSequence." - what does it
>> mean?
>>
>> The following code is valid in Chrome, but invalid in firefox and IE.
>>
>> var \u006eew = 1; // \u006e = 'n'
>>
>> and valid in Babel/Traceur, invalid in typescript/esprima...
>>
>> --
>> 
>> Spket IDE - Development Tool for RIA.
>>
>> http://www.spket.com
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Eric Suen]

Like Caitlin said, logically

Escaped ReservedWords is IdentifierName
Escaped ReservedWords is not ReservedWord
Identifier is IdentifierName but not ReservedWord
Escaped ReservedWords is not Identifier?

I'm writing javascript parser myself, those inconsistency really confuse me...

On Sun, Nov 8, 2015 at 2:07 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
>
>> On Nov 7, 2015, at 9:58 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>>
>> I see, I thought you were refer 'get'/'set'. Indeed escaped
>> ReservedWords should be ReservedWords.
>>
>> Class a = \u006eew Class()
>>
>> is valid in Java and C#.
>
> But not in ECMAScript 2015.  JavaScript is neither Java or C#
>
>
>



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Eric Suen]

get/set/as/from/target are valid Identifier, it can't be reserved words

On Sun, Nov 8, 2015 at 1:06 AM, Caitlin Potter <caitpotte...@gmail.com> wrote:
> It should be reserved, logically — but the spec does not explicitly forbid
> this. Unless you take Allen’s “it’s a bold sequence of characters,
> therefore…” argument, which is all well and good, but is only really
> explained in the spec in http://tc39.github.io/ecma262/#sec-grammar-notation
> in the first paragraph — and then further, unicode escapes tend to be
> eagerly converted, so “appear in a script exactly as written” can be
> misleading. Explicit static semantics work a lot better for this sort of
> thing, as they can be easily referenced.
>
> So, in that case, it’s SpiderMonkey with the bug in the case of accessor
> methods, and Chrome without it, while Firefox behaves correctly with escaped
> `new . target`, and Chrome doesn’t.
>
>
> On Nov 7, 2015, at 11:57 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>
> So escaped ReservedWords are not valid as ReservedWords nor
> Identifier, what is it then?
>
> And in export { IdentifierName }, why it's IdentifierName not
> Identifier. since IdentifierName only valid as Property in
> ObjectLiteral or Method in Class, is there any way to define
> ReservedWords as local name?
>
> 'get'/'set' is ContextuallyReservedIdentifier, maybe that's the reason?
>
>
> On Sat, Nov 7, 2015 at 11:32 PM, Caitlin Potter <caitpotte...@gmail.com>
> wrote:
>
> That it works in Chrome is a bug, which will hopefully be fixed by Monday or
> Tuesday!
>
> Per http://tc39.github.io/ecma262/#sec-keywords, “new” is a Keyword, which
> makes it a ReservedWord.
>
> Per
> http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors,
> under the
> “Identifier: IdentifierName but not ReservedWord” section, the second early
> error applies here. This applies to
> `new`, which is always a reserved word. So whenever an Identifier is
> expected, if it contains UnicodeEscapeSequences which result in the same
> StringValue as a ReservedWord, it’s an error.
>
> The spec is similarly explicit in saying that escaped ReservedWords are not
> valid as ReservedWords. Browsers behave differently here (for instance,
> http://jsfiddle.net/jd51pqae/ <<< at the time of this writing Webkit Nightly
> prints the text, while other browsers SyntaxError. in Chromes case, this is
> because it’s tokenized as an Identifier, so the second Identifier “f” is
> unexpected when parsing a MemberExpression. SpiderMonkey is doing a nice job
> of reporting clean errors for this kind of thing, that are easier to
> understand.
>
> There are some odd points though:
>
> 1. ReservedWord restrictions never apply to `get` or `set`, even in
> ObjectLiterals (though currently Chrome fails to treat `g\u{65}t` or
> `s\u{65}t` as an accessor prefix, this is a bug).
>
> 2. In the case of “new.target”, it’s technically legal to write
> `new.t\u{61}rget`, but this mostly just seems like an oversight in the spec.
>
> On Nov 7, 2015, at 9:50 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>
> "The ReservedWord definitions are specified as literal sequences of
> specific SourceCharacter elements. A code point in a ReservedWord
> cannot be expressed by a \ UnicodeEscapeSequence." - what does it
> mean?
>
> The following code is valid in Chrome, but invalid in firefox and IE.
>
> var \u006eew = 1; // \u006e = 'n'
>
> and valid in Babel/Traceur, invalid in typescript/esprima...
>
> --
> 
> Spket IDE - Development Tool for RIA.
>
> http://www.spket.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
> --
> 
> Spket IDE - Development Tool for RIA.
>
> http://www.spket.com
>
>



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Eric Suen]

I see, I thought you were refer 'get'/'set'. Indeed escaped
ReservedWords should be ReservedWords.

Class a = \u006eew Class()

is valid in Java and C#.

On Sun, Nov 8, 2015 at 1:20 AM, Caitlin Potter <caitpotte...@gmail.com> wrote:
> You seem to be misunderstanding me
>
>> On Nov 7, 2015, at 12:18 PM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>>
>> get/set/as/from/target are valid Identifier, it can't be reserved words
>>
>>> On Sun, Nov 8, 2015 at 1:06 AM, Caitlin Potter <caitpotte...@gmail.com> 
>>> wrote:
>>> It should be reserved, logically — but the spec does not explicitly forbid
>>> this. Unless you take Allen’s “it’s a bold sequence of characters,
>>> therefore…” argument, which is all well and good, but is only really
>>> explained in the spec in http://tc39.github.io/ecma262/#sec-grammar-notation
>>> in the first paragraph — and then further, unicode escapes tend to be
>>> eagerly converted, so “appear in a script exactly as written” can be
>>> misleading. Explicit static semantics work a lot better for this sort of
>>> thing, as they can be easily referenced.
>>>
>>> So, in that case, it’s SpiderMonkey with the bug in the case of accessor
>>> methods, and Chrome without it, while Firefox behaves correctly with escaped
>>> `new . target`, and Chrome doesn’t.
>>>
>>>
>>> On Nov 7, 2015, at 11:57 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>>>
>>> So escaped ReservedWords are not valid as ReservedWords nor
>>> Identifier, what is it then?
>>>
>>> And in export { IdentifierName }, why it's IdentifierName not
>>> Identifier. since IdentifierName only valid as Property in
>>> ObjectLiteral or Method in Class, is there any way to define
>>> ReservedWords as local name?
>>>
>>> 'get'/'set' is ContextuallyReservedIdentifier, maybe that's the reason?
>>>
>>>
>>> On Sat, Nov 7, 2015 at 11:32 PM, Caitlin Potter <caitpotte...@gmail.com>
>>> wrote:
>>>
>>> That it works in Chrome is a bug, which will hopefully be fixed by Monday or
>>> Tuesday!
>>>
>>> Per http://tc39.github.io/ecma262/#sec-keywords, “new” is a Keyword, which
>>> makes it a ReservedWord.
>>>
>>> Per
>>> http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors,
>>> under the
>>> “Identifier: IdentifierName but not ReservedWord” section, the second early
>>> error applies here. This applies to
>>> `new`, which is always a reserved word. So whenever an Identifier is
>>> expected, if it contains UnicodeEscapeSequences which result in the same
>>> StringValue as a ReservedWord, it’s an error.
>>>
>>> The spec is similarly explicit in saying that escaped ReservedWords are not
>>> valid as ReservedWords. Browsers behave differently here (for instance,
>>> http://jsfiddle.net/jd51pqae/ <<< at the time of this writing Webkit Nightly
>>> prints the text, while other browsers SyntaxError. in Chromes case, this is
>>> because it’s tokenized as an Identifier, so the second Identifier “f” is
>>> unexpected when parsing a MemberExpression. SpiderMonkey is doing a nice job
>>> of reporting clean errors for this kind of thing, that are easier to
>>> understand.
>>>
>>> There are some odd points though:
>>>
>>> 1. ReservedWord restrictions never apply to `get` or `set`, even in
>>> ObjectLiterals (though currently Chrome fails to treat `g\u{65}t` or
>>> `s\u{65}t` as an accessor prefix, this is a bug).
>>>
>>> 2. In the case of “new.target”, it’s technically legal to write
>>> `new.t\u{61}rget`, but this mostly just seems like an oversight in the spec.
>>>
>>> On Nov 7, 2015, at 9:50 AM, Eric Suen <eric.suen.t...@gmail.com> wrote:
>>>
>>> "The ReservedWord definitions are specified as literal sequences of
>>> specific SourceCharacter elements. A code point in a ReservedWord
>>> cannot be expressed by a \ UnicodeEscapeSequence." - what does it
>>> mean?
>>>
>>> The following code is valid in Chrome, but invalid in firefox and IE.
>>>
>>> var \u006eew = 1; // \u006e = 'n'
>>>
>>> and valid in Babel/Traceur, invalid in typescript/esprima...
>>>
>>> --
>>> 
>>> Spket IDE - Development Tool for RIA.
>>>
>>> http://www.spket.com
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 
>>> Spket IDE - Development Tool for RIA.
>>>
>>> http://www.spket.com
>>
>>
>>
>> --
>> 
>> Spket IDE - Development Tool for RIA.
>>
>> http://www.spket.com



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax to get same object that method was called on (Easy methodchaining)

[Eric Suen]

with

 obj.(doSomething(), doSomething2());

you don’t need to introduce new operator.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why is no line break is needed in ArrowFunction?

[Eric Suen]

Why not remove Headless Arrow Functions from ExpressionStatement like
FunctionExpression and ObjectLiteral.

then statement like:

var a = i
 => 1

will be
var a = i => 1;

instead of

var a = i;
=> 1;

BTW why Statement[return] exists? or why there is no Statment[break]
or Statement[continue]? did I miss something?

On Thu, Oct 22, 2015 at 4:39 AM, Brian Terlson
<brian.terl...@microsoft.com> wrote:
> Sure, this works for syntax questions.
>
>
>
> Today no expression can start with =>, but there is the headless arrows
> proposal[1] which might add one. IIRC we wanted to be future compatible.
>
>
>
> I’m not sure what the motivation for [no LT here] in yield * was, but I
> support it on the grounds that splitting yield and * across lines is bad :-P
> In general better to be more conservative than less, I suppose.
>
>
>
> 1. https://bterlson.github.io/headless-arrows
>
>
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Eric
> Suen
> Sent: Wednesday, October 21, 2015 12:28 AM
> To: es-discuss@mozilla.org
> Subject: Why is no line break is needed in ArrowFunction?
>
>
>
> Try to write a parser for es6, is this the right place for question about
> syntax?
>
>
>
> There is no expression or statement start with =>, same goes to yield  [no
> LineTerminator here] * AssignmentExpression ?
>
>
>
>
> 
> Spket IDE - Development Tool for RIA.
>
> http://www.spket.com



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Why is no line break is needed in ArrowFunction?

[Eric Suen]

Try to write a parser for es6, is this the right place for question about
syntax?

There is no expression or statement start with =>, same goes to yield  [no
LineTerminator here] * AssignmentExpression ?



Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Modify automatic semicolon insertion in strict mode

[Eric Suen]

 Yuh-Ruey Chen wrote:
 Eric Suen wrote:
 Your proposal make nosense to me, first, I not sure what is your
 strict mode means, because in strict mode there is no automatic
 semicolon insertion.

 No, semicolon insertion occurs also in strict mode. Perhaps it shouldn't.


Oops, I got this from:

http://www.mozilla.org/js/language/js20-2002-04/core/pragmas.html#strict-mode


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

This is ambiguous

{(a, b)
a + b}

is

{(a,b);
a+b
}

unless use no line break restrict and it is difficult to parse

P T Withington wrote:
 Would it work to move the parameter list inside the block (as in the
 Smalltalk way, but as a regular parameter list, not using ||'s)?

   {(a, b) a + b}

 AFAICT, `{(` is a syntax error for an expression in es3.

 I think this is unambiguous, but I don't like it because it has no
 symbol or combination of symbols that is specific to a lambda.
 ( {( can occur as the start of a block.)

 -- 
 David-Sarah Hopwood 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

But in page:

http://wiki.ecmascript.org/doku.php?id=strawman:lambdas

lambda is not just a expression, it could be a Declaration.

If lambda is only a expression, that is why I suggest in post:

https://mail.mozilla.org/pipermail/es-discuss/2008-December/008382.html

 This is ambiguous

 {(a, b)
 a + b}

 is

 {(a,b);
 a+b
 }

 This example isn't ambiguous, because an ExpressionStatement cannot start
 with '{', therefore this is a block. However the fact that a lambda
 starting an ExpressionStatement would have to be parenthesized is a
 valid argument against this syntax, and also against {|a, b| a+b}.

 unless use no line break restrict and it is difficult to parse

 It's not actually difficult to parse (since an object literal cannot
 have '(' after the '{'), but I don't think it has any advantages over
 syntaxes starting with '^' or '\'.


 ('^' is back on the table given that the semicolon insertion hazard
 that caused us to be suspicious of it, already exists when a line
 starts with '(', for example.)

 -- 
 David-Sarah Hopwood 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

Why not using two version, one is for definition like:

Lambda name (a,b,c) {
}

and for expression, you can use both, like:

a = lambda (a,b,c) {
}

and

a = (a,b,c) {
}

 Yes, it doesn't contain a lambda expression, just like:

 a = x
 /x/i

 is not same as:

 a = x;
 /x/i

 they both right but has different meaning...

 Okay -- so we agree.  In that case, it's clear that your proposed syntax:

   (a,b,c) {...}

 has the same problem, right?  Any valid ES3 infix operator will have
 the same problem, if we use it as a prefix lambda operator. 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

No, \ worse than '^' or '', why not use

function ^ Identifier ( parameters ) block for declaration

and use

^ IdentifierOpt ( parameters ) block for expression

ExpressionStatement ::= [lookahead !{ {, function, ^ }] CommaExpression


 Okay -- so we agree.  In that case, it's clear that your proposed syntax:

   (a,b,c) {...}

 has the same problem, right?  Any valid ES3 infix operator will have
 the same problem, if we use it as a prefix lambda operator.



 Welcome to the syntax races. lambda takes an early lead, but drops back
 because of too much weight. For a while, it's neck and neck between || and
 ^, with \ following closely and fn, , and other trailing. Many old
 timers (including your commentator) are rooting for || because of its
 previous historic performances. But || trips up over ambiguities not
 present on its original track. ^ is now in the lead. Oh no! It trips on a
 different ambiguity. This track seems riddled with more ambiguities than any
 of these contenders have ever trained on. Seeing ^ stumble,  and other
 contenders saddled with binary operatorness, drop back and concede. \
 has taken the lead

 -- 
   Cheers,
   --MarkM
 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

In feature(ES4), ES may have OptionalParameter, that will cause trouble

{ |a ,b = 1 | c | d | e | f }

is

{ (|a ,b = 1 |) c | d | e | f }

or

{ (|a ,b = 1 | c) | d | e | f }

Regards,

Eric Suen

- Original Message - 
From: Yuh-Ruey Chen [EMAIL PROTECTED]
To: Brendan Eich [EMAIL PROTECTED]
Cc: Eric Suen [EMAIL PROTECTED]; Maciej Stachowiak 
[EMAIL PROTECTED]; es-discuss 
es-discuss@mozilla.org
Sent: Wednesday, December 03, 2008 8:56 PM
Subject: Re: Allen's lambda syntax proposal


 Brendan Eich wrote:
 C# uses (a, b, c) = ... but in JS the comma operator makes that nasty
 to parse top-down. I think the only candidates have to be of the form

 ^(a, b, c) {...}

 (^ could be another character, but it seems to beat \ as others have
 noted), or else the Smalltalky

 { |a, b, c| ... }

 At this point we need a bake-off, or a convincing argument against the
 unusual vertical bar usage.

 Here's a possible technical issue that might not apply to ES: Ruby
 blocks params can't have default arguments according to
 http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :

The new syntax allows to specify default values for block arguments,
since

 {|a,b=1| ... }


is said to be impossible with Ruby's current LALR(1) parser, built
with bison.


 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

In that case, you have to rewrite the grammar from:

OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn]

to

OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn,noOR]

Make it necessary complicated.

 In feature(ES4), ES may have OptionalParameter, that will cause trouble

 { |a ,b = 1 | c | d | e | f }

 is

 { (|a ,b = 1 |) c | d | e | f }

 or

 { (|a ,b = 1 | c) | d | e | f }

 Regards,

 Eric Suen


 That should be a syntax error. Parenthesis should be required in that
 case to avoid ambiguity: {|a, b = (1 | c)| ... } 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

Because it is a xor expression, for lambda, it will be

x = x * x ^ ^ (a,b,c,d,e,f,g)
{
  x
}

it is same for regexp,

x = x / x /i

is not regexp, but

x = x / /x/i

is regexp

seems that ^ will confuse lots of people

- Original Message - 
From: Jon Zeppieri [EMAIL PROTECTED]
To: Eric Suen [EMAIL PROTECTED]
Cc: Jon Zeppieri [EMAIL PROTECTED]; es-discuss 
es-discuss@mozilla.org
Sent: Thursday, December 04, 2008 10:45 AM
Subject: Re: Allen's lambda syntax proposal


 On Wed, Dec 3, 2008 at 9:36 PM, Eric Suen [EMAIL PROTECTED] wrote:


 No,

 ^(x) is not a legal expression, so you don't have to make
 block in same line, no semicolon insertion will happens here.

 You're looking at the wrong part of the example.  Sorry -- the
 wrapper lambda is superfluous, and I should have left it out for
 clarity.

 Using the GNU bracing style:

 x = x * x
 ^(a,b,c,d,e,f,g)
 {
  x
 }

 The above parses as an xor expression followed by a block, like so:

 x = x * x ^ (a,b,c,d,e,f,g)
 {
  x
 }
 ... which is odd, to be sure, but perfectly legal.


 The second example:

 x = x * x
 ^(a,b,c,d,e,f,g) {x}

 is not ambiguous, but it's unsuitable for top-down parsing.  (I tried
 to underscore the point by using a long list of formals.)  The parser
 has to get to the opening brace before it can determine that it isn't
 dealing with an xor expression.

 -Jon




 see this post:

 https://mail.mozilla.org/pipermail/es-discuss/2008-December/008296.html

 - Original Message -
 From: Jon Zeppieri [EMAIL PROTECTED]
 Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
 To: P T Withington [EMAIL PROTECTED]
 Cc: es-discuss [EMAIL PROTECTED]
 Sent: Thursday, December 04, 2008 3:09 AM
 Subject: Re: Allen's lambda syntax proposal


 2008/12/3 P T Withington [EMAIL PROTECTED]:

 - prefix ^ might be confused with the infix operator of the same name

 With semicolon insertion, isn't this a bigger problem?

 The opening brace will need to be on the same line as the formals,
 otherwise the syntax is ambiguous:

 ^(x) {
  x = x * x
  ^(a,b,c,d,e,f,g)
  {
x
  }
 }

 And, if it is on the same line, it's still bad for a top-down parser:

 ^(x) {
  x = x * x
  ^(a,b,c,d,e,f,g) {x}
 }

 Will semicolon insertion be illegal inside a lambda body?

 -Jon



 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

It even can be writen as:

Lambda ::= '' IdentifierOpt ParametersOpt Block

IdentifierOpt ::= %Empty
 | PropertyIdentifier

ParametersOpt ::= %Empty
 | '(' Parameters ')'

I suggest following grammar:

 Lambda ::= '' '(' Parameters ')' Block
 | '' Block //if no parameters

 I can comfire that this rule is no problem for a LALR(k) parser,
 ES4 is not LALR(1) anyway. and I think ^ is not good for eyes, it
 is too small and may confused with ~.  look more like C/C++ style

 a =  { ... }

 a =  (a,b) { ... }

 Yuh-Ruey Chen wrote:
 Brendan Eich wrote:
 C# uses (a, b, c) = ... but in JS the comma operator makes that
 nasty to parse top-down. I think the only candidates have to be of
 the form

 ^(a, b, c) {...}

 (^ could be another character, but it seems to beat \ as others have
 noted), or else the Smalltalky

 { |a, b, c| ... }

 At this point we need a bake-off, or a convincing argument against
 the unusual vertical bar usage.

 Here's a possible technical issue that might not apply to ES: Ruby
 blocks params can't have default arguments according to
 http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :

 The new syntax allows to specify default values for block
 arguments, since

  {|a,b=1| ... }


 is said to be impossible with Ruby's current LALR(1) parser, built
 with bison.


 That Ruby 1.9 page also lists yet another possible syntax:

 -(a, b, ...) {...}

 Using Maciej's examples:

 if_ (-{x  3}, -{
handleSmallNum(x);
 }, -{
handleLargeNum(x);
 });

 while_ (-{x != null}, -{
   x.process();
   x = x.next();
 });

 for_ (-{var i = 1}, -{i  10}, -{i++}, -{
total += vec[i];
 });

 forIn_ (obj, -(prop) {
props.push(prop);
 });

 arr.sort(-(a, b) { a*a  b*b });
 arr.map(-(x) { x * (x-1)});

 function doubleBs(str) {
str.replace(/b*/, -(substr) { substr + substr });
 }

 The control abstractions just don't look right, regardless of which
 lambda syntax we choose. I'd rather wait for a more powerful macro
 system, instead of choosing the syntax based off how it would look in
 control abstractions.
 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

Yes, it doesn't contain a lambda expression, just like:

a = x
/x/i

is not same as:

a = x;
/x/i

they both right but has different meaning...

 Because it is a xor expression, for lambda, it will be

 x = x * x ^ ^ (a,b,c,d,e,f,g)
 {
  x
 }

 I don't understand what you're getting at.  That's a syntax error.  My 
 example:

 x = x * x
 ^(a,b,c,d,e,f,g)
 {
  x
 }

 is not a syntax error, but it also (unfortunately) doesn't contain a
 lambda expression.  Or am I missing something?

 -Jon 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

'~' is ambiguities usless you using two NO_LINE_BREAK like:

'~' NO_LINE_BREAK (...) NO_LINE_BREAK {...}

'.' may not looks good, but it does not introduce new token
like '\' or 'lambda'

Regards,

Eric Suen

- Original Message - 
From: Maciej Stachowiak [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Eric Suen [EMAIL PROTECTED]
Cc: Brendan Eich [EMAIL PROTECTED]; 
es-discuss [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2008 12:48 AM
Subject: Re: Allen's lambda syntax proposal



 On Dec 2, 2008, at 5:03 AM, Eric Suen wrote:

 What about:

 .(a,b,c) {}

 or

 ..(a,b,c) {}

 or

 ...(a,b,c) {}

 As long as we're giving the bikeshed a few more coats of paint,  Objective-C 
 is adding block-like closures with ^ as the prefix, so we  could take 
 inspiration from that:

 ^(a, b, c) { ... }

 I'm not sure if this would introduce ambiguities in the grammar since  ^ is 
 already an operator; I tend to think not, because + and -  manage to be 
 both unary and binary operators without ambiguity. ^  also has a slight 
 resemblance to the greek lambda, which is the reason  Haskell uses \. This 
 could support named lambdas without risk of  clashing with the \u escape.

 Regards,
 Maciej



 Regards,

 Eric Suen

 - Original Message -
 From: Allen Wirfs-Brock
 [EMAIL PROTECTED]
 Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
 To: Maciej Stachowiak 
 [EMAIL PROTECTED]; 
 Brendan
 Eich 
 [EMAIL PROTECTED]
 Cc: 
 [EMAIL PROTECTED]
 Sent: Tuesday, December 02, 2008 6:32 AM
 Subject: RE: Allen's lambda syntax proposal


 {|a,b,c| ...} or
 \(a,b,c) {...} or
 {\(a,b,c) ...}

 I could be happy with any of them and can find pros and cons with  each.  I
 think the high order bit should be that a concise closure syntax is 
 possible
 and desirable. If we agree on that then we just need to pick one.

 The use of \ slightly bothers me because it is takes a character  that now 
 is
 exclusively used in the lexical (token) grammar ( Unicode escapes,  string
 escapes, line continuations)  and gives it syntactic significance.  This is
 probably not a fatal flaw but it would mean that the lexical uses  of \ 
 become
 less visually distinctive.

 Whether someone prefers the parameters inside or outside the braces  may be
 another symptom of whether they are focusing on control abstraction  or
 functional abstraction. With control abstraction you use closures  as 
 blocks
 of code that form pieces of the abstraction so it may seems natural  from 
 that
 perspective for the braces to surround the entire block. This is  closer 
 to
 the syntactic feel of the built-in control statements.  If you are  building
 functional abstractions then you are probably thinking about the  closures 
 as
 functions so placing the formals before the body seems natural.

 It's fairly common with control abstractions to use 0 argument  closures so 
 the
 readability of {||...}, \(){...}, and {\()...} are probably also  worth
 considering.  Ideally a 0 argument closure would be written as  {...} but
 resolution of the syntactic ambiguities between object literal and  such
 closures (particularly in the presence of statement labels) seems too
 difficult to contend with.

 My focus on supporting control abstraction may be mute.  While  Smalltalk 
 and
 Ruby show that power of such abstraction mechanisms it takes more  than 
 just 
 a
 concise block-like closure notation to achieve it. The complexity  of the 
 BGGA
 Java closure proposal (and the associated controversy) shows how  hard it 
 can
 be to fully support control abstraction using C syntax (and, of  course, 
 Java
 semantics).

 Allen

 -Original Message-
 From: 
 [EMAIL PROTECTED]
 [mailto:es-discuss-
 [EMAIL PROTECTED] On 
 Behalf Of Maciej
 Stachowiak
 Sent: Monday, December 01, 2008 12:59 PM
 To: Brendan Eich
 Cc: 
 [EMAIL PROTECTED]
 Subject: Re: Allen's lambda syntax proposal


 On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:

 At the TC39 meeting two weeks ago in Kona, we had a brief
 bikeshedding discussion about lambda syntax and why it matters.
 Observation: blocks in Smalltalk being lightweight means users  don't
 mind writing them for control abstractions, compared to JS  functions
 in ES3. In Smalltalk, ignoring JS, it's hard to beat [ and ] as
 overhead, although one must count the message selector and its
 punctuation too.

 Allen Wirfs-Brock put his proposal, which will not shock you who
 know Smalltalk or Allen, on the whiteboard:

 // Instead of lambda (a, b, c) { ... }, why not:
 { |a, b, c| ... } ?

 I like the brevity, but having the formals inside the block and in  ||
 delimiters seems like it will look weird in an ECMAScript program.  For
 function declarations the parameters go in parentheses, and for  calls
 (presumably also for lambda calls), the arguments go in parens. If
 brevity is important, why not lift the lambda syntax from modern  pure
 functional languages:

 \(a, b, c) { ... }

 That's

Re: where both a division and a RegularExpressionLiteral are permitted

[Eric Suen]

a = a
 /a/

this will cause syntax error instead of

a = a;
/a/

Regards,

Eric Suen

- Original Message - 
From: David-Sarah Hopwood 
[EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: [EMAIL PROTECTED]
Sent: Sunday, November 30, 2008 9:41 AM
Subject: where both a division and a RegularExpressionLiteral are permitted


 Section 7 (Lexical Conventions):

 # Note that contexts exist in the syntactic grammar where both a division
 # and a RegularExpressionLiteral are permitted by the syntactic grammar;
 # [...]

 I believe this statement is incorrect [*1].
 If I'm wrong, what is an example of such a context?


 [*1] A DivisionPunctuator must be preceded by an expression.
 A RegularExpressionLiteral is itself an expression.
 Therefore, for there to exist syntactic contexts in which either
 a DivisionPunctuator or a RegularExpressionLiteral could occur,
 it would have to be possible for an expression to immediately
 follow [*2] another expression with no intervening operator.
 The only case in which that can occur is where a semicolon is
 automatically inserted between the two expressions.
 Assume that case: then the second expression cannot begin
 with [*2] a token whose first character is '/', because that
 would have been interpreted as a DivisionPunctuator, and so
 no semicolon insertion would have occurred (because semicolon
 insertion only occurs where there would otherwise have been a
 syntax error); contradiction.

 [*2] Ignoring comments and whitespace.

 -- 
 David-Sarah Hopwood 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of destructuring

[Eric Suen]

Will destructuring and closures be included in ES3.1?

Where can I find the grammar of destructuring and closures in
mozilla JavaScript 1.8, because in mozilla docs site only list
some examples, that is not enough for write a parser.

Regards,

Eric Suen

- Original Message - 
From: Brendan Eich [EMAIL PROTECTED]
To: Eric Suen [EMAIL PROTECTED]
Cc: es-discuss es-discuss@mozilla.org; Jeff Dyer [EMAIL PROTECTED]
Sent: Sunday, November 09, 2008 11:15 AM
Subject: Re: Question of destructuring


 On Nov 8, 2008, at 9:40 AM, Eric Suen wrote:

 https://developer.mozilla.org/en/New_in_JavaScript_1.7

 has following statement:

 for each (let {name: n, family: { father: f } } in people) {
  print (Name:  + n + , Father:  + f + br\n);
 }

 But in http://www.ecmascript.org/es4/spec/grammar.pdf

 ForInBinding ::= Pattern
  | VariableDefinitionKind VariableBinding

 VariableBinding ::= TypedIdentifier
  | TypedPattern VariableInitialisation

 VariableInitialisation ::= '=' AssignmentExpression

 Obviously let {name: n, family: { father: f } } is not a Pattern,
 So, how the above statement is valid?

 It's a bug, thanks for pointing it out. The ES4 grammar is not being 
 maintained now AFAIK. Cc'ing Jeff.

 /be
 


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: return when desugaring to closures

[Eric Suen]

 The parser is required to backtrack until it either finds an
 expansion of the grammar that doesn't generate a syntax error or
 until it discovers that they all do.  You can choose to make
 additional syntax errors as per chapter 16, but that does not
 relieve you of the backtracking requirement.

 You're right that a bottom up parser will have a reduce-reduce
 conflict. For a top-down parser, it's not an issue.


Are you sure about that, because you using hand written top-down parser,
Is it confirmed by a top-down parser generator like ANTLR?

I think top-down parser has no issue to parse following code:

function() {
}();

but this is not a valid statement because:

ExpressionStatement ::= [lookahead ! {{, function}] Expression ;

This kind question I asked long time ago, but no one answed,

https://mail.mozilla.org/pipermail/es-discuss/2008-July/006640.html

and now seems write a bottom up JS parser is mission impossible.

Regards,

Eric Suen



___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss