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'.
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,
On 3/30/08, Jeff Dyer <jodyer at adobe.com> wrote:
Hi,
I've updated the ES4 grammar files linked from
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?
- 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.
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.
Maybe I spoke too soon on that point-- depending on the array types, it might not be problematic. But it certainly would be problematic to type-check splatting into the middle of the actuals list for a function call.
Does the order of rules means different priority? otherwise why PropertyName is same as PrimaryName, and what is that number before each rule means?
Eric Suen
On 3/31/08 8:12 AM, Eric Suen wrote:
Hi,
Does the order of rules means different priority?
The order of the rules has no meaning.
otherwise why PropertyName is same as PrimaryName,
These two symbols have converged with recent changes. The use of PropertyName in PropertyOperator should be replaced with PrimaryName, and the definition of PropertyName should be removed from the grammar. Good catch!
and what is that number before each rule means?
The edition of ECMAScript that the production was introduced.
It's not clear that 'has' should be removed, but it could be removed for the time being. The discussion on this list in the past couple of weeks (Subject: "ES4 draft: Object initializers") indicates that the following forms should possibly be allowed for catchalls:
{ get() ..., set() ..., has() ..., delete() ... invoke() ... }
These forms create fixtures and stand for the meta::invoke etc methods. Anyhow those five names become reserved contextually. All of that is of course subject to further discussion as soon as I can get a new draft out of the feature spec.
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.
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.
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.
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:
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.
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]
,
Eric Suen
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 ---
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.
On Sun, Mar 30, 2008 at 7:29 PM, Jeff Dyer <jodyer at adobe.com> wrote:
I've updated the ES4 grammar files linked from 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.
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:
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.
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:
doku.php? id=proposals:iterators_and_generator s
This is my fault -- I went by the examples in
www.python.org/dev/peps/pep-0202
and did not include the full grammar from
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.
-----Original Message----- From: Brendan Eich [mailto:brendan at mozilla.org] 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:
doku.php? id=proposals:iterators_and_generator s
This is my fault -- I went by the examples in
www.python.org/dev/peps/pep-0202
and did not include the full grammar from
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.)
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.
I've updated the ES4 grammar files linked from
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:
spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=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!