RE: grammar update
Looks like those restrictions (condition only at the end, only 'for', 'for each', and 'if' clauses) originate in Brendan's original (too-sketchy) proposal, see the Comprehensions section of this page: http://wiki.ecmascript.org/doku.php?id=proposals:iterators_and_generator s IMO we're looking for simple and useful comprehensions for ES4. I think extensions like the ones you are suggesting, though clearly useful, should be prototyped elsewhere before going into the language spec, or at a minimum, be presented in a better developed proposal. --lars -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Orendorff Sent: 2. april 2008 13:46 To: Jeff Dyer Cc: es4-discuss Subject: Re: grammar update On Sun, Mar 30, 2008 at 7:29 PM, Jeff Dyer [EMAIL PROTECTED] wrote: I've updated the ES4 grammar files linked from http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar Thanks for doing this. I noticed that the grammar doesn't allow this: [addr for each (user in users) if (user.isAdministrator) for each (addr in user.addresses)] Is this intentional? Both Python and Haskell allow the analogous listcomp. (Oddly enough, if you anti-optimize this, moving the IfCondition to be after the last ForInExpression, the proposed ES4 grammar accepts that.) Separately, I would appreciate let clauses in ArrayComprehensions: [[trial, phi] for each (trial in trials) let (phi = hugeExpensiveCalculation(trial)) if (phi 1000)] Haskell has this feature. I occasionally reach for it in Python and it isn't there. -j ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
On Apr 2, 2008, at 1:03 PM, Lars Hansen wrote: Looks like those restrictions (condition only at the end, only 'for', 'for each', and 'if' clauses) originate in Brendan's original (too-sketchy) proposal, see the Comprehensions section of this page: http://wiki.ecmascript.org/doku.php? id=proposals:iterators_and_generator s This is my fault -- I went by the examples in http://www.python.org/dev/peps/pep-0202/ and did not include the full grammar from http://www.python.org/doc/current/ref/lists.html#l2h-238 cited therein -- apologies to all and thanks to Jason for pointing this out. IMO we're looking for simple and useful comprehensions for ES4. I think extensions like the ones you are suggesting, though clearly useful, should be prototyped elsewhere before going into the language spec, or at a minimum, be presented in a better developed proposal. This is all thin syntactic sugar, so I don't agree it rocks the boat too much to follow the full prototype in Python. I'll update the proposal, since it claims to follow the PEP, but fails since the PEP cites the RM. Jason wrote: Separately, I would appreciate let clauses in ArrayComprehensions: [[trial, phi] for each (trial in trials) let (phi = hugeExpensiveCalculation(trial)) if (phi 1000)] Haskell has this feature. I occasionally reach for it in Python and it isn't there. Lars, you didn't cite this use-case for let statements, aka let blocks :-P. Firefox 2 and 3 (JS1.7 and 1.8) have support for let blocks, but again not embedded in comprehensions. As Jason notes, Python didn't follow Haskell here (if that was the order of evolution). I don't propose we do this for ES4, since let blocks are out according to all who've opined on the spreadsheet. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: grammar update
-Original Message- From: Brendan Eich [mailto:[EMAIL PROTECTED] Sent: 2. april 2008 17:15 To: Lars Hansen Cc: Jason Orendorff; Jeff Dyer; es4-discuss Subject: Re: grammar update On Apr 2, 2008, at 1:03 PM, Lars Hansen wrote: Looks like those restrictions (condition only at the end, only 'for', 'for each', and 'if' clauses) originate in Brendan's original (too-sketchy) proposal, see the Comprehensions section of this page: http://wiki.ecmascript.org/doku.php? id=proposals:iterators_and_generator s This is my fault -- I went by the examples in http://www.python.org/dev/peps/pep-0202/ and did not include the full grammar from http://www.python.org/doc/current/ref/lists.html#l2h-238 cited therein -- apologies to all and thanks to Jason for pointing this out. IMO we're looking for simple and useful comprehensions for ES4. I think extensions like the ones you are suggesting, though clearly useful, should be prototyped elsewhere before going into the language spec, or at a minimum, be presented in a better developed proposal. This is all thin syntactic sugar, so I don't agree it rocks the boat too much to follow the full prototype in Python. I'll update the proposal, since it claims to follow the PEP, but fails since the PEP cites the RM. The PEP is scarcely relevant; what we need are comprehensive proposals for ES4. Jason wrote: Separately, I would appreciate let clauses in ArrayComprehensions: [[trial, phi] for each (trial in trials) let (phi = hugeExpensiveCalculation(trial)) if (phi 1000)] Haskell has this feature. I occasionally reach for it in Python and it isn't there. Lars, you didn't cite this use-case for let statements, aka let blocks :-P. Firefox 2 and 3 (JS1.7 and 1.8) have support for let blocks, but again not embedded in comprehensions. As Jason notes, Python didn't follow Haskell here (if that was the order of evolution). I don't propose we do this for ES4, since let blocks are out according to all who've opined on the spreadsheet. The syntax Jason uses is not for let blocks, but for let expressions. Not that I see how it matters, since surely the 'for each' and 'if' forms in array comprehensions are not meant to be taken to be the same as their statement counterparts in all ways. Please do update the spec for comprehensions; I will not make it my job to figure out what you meant by studying Python. The spec that's there is too informal as well, consisting only of illustrative examples. It needs (probably) a grammar and semantics at a minimum. (The page the generator proposal is on is already far too large; I suggest that you break generators out as a separate proposal.) --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
On Apr 2, 2008, at 6:01 PM, Lars Hansen wrote: This is all thin syntactic sugar, so I don't agree it rocks the boat too much to follow the full prototype in Python. I'll update the proposal, since it claims to follow the PEP, but fails since the PEP cites the RM. The PEP is scarcely relevant; what we need are comprehensive proposals for ES4. Touché (again; last time, I won't grovel :-/). My point is that the proposal is intended to avoid novelty in comparison to Python, especially novelty due to my poor mistake. Not all of ES4 is yet fully or even well-specified (e.g., packages -- this was clear from the last TC39 meeting). But where use-cases are strong, we are persevering, not rejecting over surface-syntax transcription errors, or even deeper issues. The syntax Jason uses is not for let blocks, but for let expressions. Syntax is secondary to context in making the point that let forms containing statements are useful. I'm not quibbling, or trying to revive let statements; I am simply citing a use case for the record. Not that I see how it matters, since surely the 'for each' and 'if' forms in array comprehensions are not meant to be taken to be the same as their statement counterparts in all ways. They de-sugar internally to statements. The implementation in JS1.7 transforms the AST in the obvious way before handing it off to the code generator. The only new AST node is the one representing the consumer of the displayed expression (the expression on the left of 'for'), which is a built-in form of Array push, as noted in the proposal. These are not anything but statements as far as the programmer can tell, but of course the syntax is restricted. I'm happy to fix the unintended over-restriction. Please do update the spec for comprehensions; I will not make it my job to figure out what you meant by studying Python. The spec that's there is too informal as well, consisting only of illustrative examples. It needs (probably) a grammar and semantics at a minimum. Ok. (The page the generator proposal is on is already far too large; I suggest that you break generators out as a separate proposal.) Will do. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
Hi,
the statement is:
var a = function() type function() like AAA
RelationalExpression ::= RelationalExpression like TypeExpression
RelationalExpression - PostfixExpression - PrimaryExpression
- FunctionExpression
FunctionExpression ::= function FunctionSignature FunctionExpressionBody
FunctionExpressionBody ::= AssignmentExpression
AssignmentExpression - ConditionalExpression - UnaryTypeExpression
- type TypeExpression - type FunctionType
- type function FunctionSignature
FunctionSignature ::= TypeParameters '(' Parameters ')' ResultType
ResultType ::= $empty
| ':' 'void'
| ':' TypeExpression
| 'like' TypeExpression -- conflict on this rule with $empty
So, is it
var a = FunctionExpression like AAA
or
var a = function() type FunctionType
- Original Message -
From: Eric Suen [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: [EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 7:35 PM
Subject: Re: grammar update
Page 11
FunctionDeclaration ::= function FunctionName FunctionSignature
should be
FunctionDeclarationW ::= function FunctionName FunctionSignature SemicolonW
following statement:
type function() like AAA
Should it be:
RelationalExpression like TypeExpression (like is operator)
[type function()] like [AAA]
or
type FunctionType (like is ResultType)
type [function() like AAA]
Regards,
Eric Suen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
It should be
var a = (function () type function ()) like AAA
In other words, your first option
var a = FunctionExpression like AAA
where AAA must be a TypeExpression.
Jd
On 4/1/08 8:37 PM, Eric Suen wrote:
Hi,
the statement is:
var a = function() type function() like AAA
RelationalExpression ::= RelationalExpression like TypeExpression
RelationalExpression - PostfixExpression - PrimaryExpression
- FunctionExpression
FunctionExpression ::= function FunctionSignature FunctionExpressionBody
FunctionExpressionBody ::= AssignmentExpression
AssignmentExpression - ConditionalExpression - UnaryTypeExpression
- type TypeExpression - type FunctionType
- type function FunctionSignature
FunctionSignature ::= TypeParameters '(' Parameters ')' ResultType
ResultType ::= $empty
| ':' 'void'
| ':' TypeExpression
| 'like' TypeExpression -- conflict on this rule with $empty
So, is it
var a = FunctionExpression like AAA
or
var a = function() type FunctionType
- Original Message -
From: Eric Suen [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: [EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 7:35 PM
Subject: Re: grammar update
Page 11
FunctionDeclaration ::= function FunctionName FunctionSignature
should be
FunctionDeclarationW ::= function FunctionName FunctionSignature SemicolonW
following statement:
type function() like AAA
Should it be:
RelationalExpression like TypeExpression (like is operator)
[type function()] like [AAA]
or
type FunctionType (like is ResultType)
type [function() like AAA]
Regards,
Eric Suen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
Hi, Does the order of rules means different priority? otherwise why PropertyName is same as PrimaryName, and what is that number before each rule means? Regards Eric Suen ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
On 3/31/08 10:33 AM, Lars Hansen wrote: I disagree that 'enum' should be reserved in ES4. E262-3 ch 16 is explicit in allowing syntactic extensions and it appears that Opera and Firefox do not reserve 'enum', suggesting that 'enum' is not in use on the public web. I don't remember why we decided to add 'enum' to ReservedIdentifiers. Perhaps it was sympathy with the other three. Perhaps Brendan will remember. Which are the three other IE reserved words? So far as I can see, the list of reserved and contextually reserved identifiers contain only ES4 keywords. They are 'class', 'extends' and 'super'. Of these 'extends' should be contextually reserved. The other two have special meaning in a broad enough context that they should probably be generally reserved. Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
On Mar 31, 2008, at 1:24 PM, Jeff Dyer wrote: On 3/31/08 10:33 AM, Lars Hansen wrote: I disagree that 'enum' should be reserved in ES4. E262-3 ch 16 is explicit in allowing syntactic extensions and it appears that Opera and Firefox do not reserve 'enum', suggesting that 'enum' is not in use on the public web. I don't remember why we decided to add 'enum' to ReservedIdentifiers. Perhaps it was sympathy with the other three. Perhaps Brendan will remember. At one point we were entertaining an enum proposal based on JScript.NET: http://wiki.ecmascript.org/doku.php?id=proposals:enumeration_type Old Firefox and Mozilla browsers would reserve, but we unreserved 'enum' and the rest a while ago (Firefox 1.5? I forget), instead making any use of one of these words cause a strict warning. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: grammar update
Observed on page 1: 'enum' and 'wrap' do not belong in the list of reserved words. If 'has' is contextually reserved then so is 'invoke'. --lars -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Dyer Sent: 30. mars 2008 18:30 To: es4-discuss Subject: grammar update Hi, I've updated the ES4 grammar files linked from http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar This version is my best attempt to describe the syntax of the language that the ES4 working group is converging on. This convergence is reflected in the feature spreadsheet posted at: http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQgid=2 I expect the syntax described by the updated grammar to be fairly representative of the final language that will be proposed by the ES4 working group as the next edition of ECMAScript. Most of the recent changes are either bug fixes or feature cuts. There are few notable additions (SplatExpression may be the only one) or feature redesigns (use strict and LikedPattern being examples). Changes are logged in the Revision History section in the wiki and at the bottom of the spreadsheet. NOTE: I have removed from the PDF the columns that show the translation from concrete to surface syntax, as they are out of date. However, you will find these obsolete columns in the updated XLS spreadsheet. I will provide a text based description of this translation in the next week or so. Comments welcomed. Enjoy! Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
IIRC, 'enum' is one of the four extra IE reserved words that we've reserved for posterity. 'wrap' and 'has' should be removed from their respective lists. Thanks, Jd On 3/30/08 8:31 PM, Lars Hansen wrote: Observed on page 1: 'enum' and 'wrap' do not belong in the list of reserved words. If 'has' is contextually reserved then so is 'invoke'. --lars -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Dyer Sent: 30. mars 2008 18:30 To: es4-discuss Subject: grammar update Hi, I've updated the ES4 grammar files linked from http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar This version is my best attempt to describe the syntax of the language that the ES4 working group is converging on. This convergence is reflected in the feature spreadsheet posted at: http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQgid=2 I expect the syntax described by the updated grammar to be fairly representative of the final language that will be proposed by the ES4 working group as the next edition of ECMAScript. Most of the recent changes are either bug fixes or feature cuts. There are few notable additions (SplatExpression may be the only one) or feature redesigns (use strict and LikedPattern being examples). Changes are logged in the Revision History section in the wiki and at the bottom of the spreadsheet. NOTE: I have removed from the PDF the columns that show the translation from concrete to surface syntax, as they are out of date. However, you will find these obsolete columns in the updated XLS spreadsheet. I will provide a text based description of this translation in the next week or so. Comments welcomed. Enjoy! Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
On 3/30/08, Jeff Dyer [EMAIL PROTECTED] wrote:
Hi,
I've updated the ES4 grammar files linked from
http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
Thanks, Jeff.
- Allowing splat expressions in array literals is a nice addition, but
restricting them to the end of element lists seems unnecessary. Is
the purpose uniformity between array literals and array patterns?
- (Not entirely a grammar issue.) What is the intended effect of:
var o = { get x() { ... } }
delete o.x
Currently the RI allows the deletion. That seems fine, but the
grammar doesn't permit:
({ const get x() { ... } })
Could FieldKind be allowed before 'get' or 'set' in a LiteralField?
-Jon
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: grammar update
- Allowing splat expressions in array literals is a nice addition, but restricting them to the end of element lists seems unnecessary. Is the purpose uniformity between array literals and array patterns? Almost: uniformity between array literals and function calls. But another issue was typeability-- it won't be possible for a statically typed mode to type-check splicing in the middle of an array. But even if we allowed splatting in the middle of *both* array literals and function calls (though a statically typed mode would reject them), the patterns would still probably need to be more restricted, which can be confusing. Dave ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
