Discuss
  • Some bugs of Spec.

Some bugs of Spec.

# Eric Suen (18 years ago)

From: www.compilercompany.com/es4/grammar.pdf

Qualifier ::= * | ReservedNamespace | Identifier

Because in spec., the Identifier has no boldface, so it conflict on ['internal', 'public'...] between Identifier and ReservedNamespace

QualifiedNameIdentifier ::= * | Identifier | ReservedIdentifier | String | Number | Brackets | OverloadedOperator

String should be StringLiteral and Number should be NumberLiteral?

ForInExpressionList ::= ForExpression | ForExpressionList ForExpression

There is no ForExpression and ForExpressionList, only ForInExpression and ForInExpressionList

NullableTypeExpression ::= 'undefined' | TypeExpression

but TypeExpression -> TypeExpression -> PrimaryName -> PropertyName -> NonAttributeQualifiedName -> SimpleQualifiedName -> Identifier -> ContextuallyReservedIdentifier -> 'undefined'

ThisExpression ::= this | this callee | this generator

What is callee and generator? not found in ReservedIdentifier or ContextuallyReservedIdentifier

BTW: where can I find the more recent spec.

# Jeff Dyer (18 years ago)

Eric,

Good finds. I've posted an updated grammar, with some additional pending fixes, at the usual place.

As for an updated spec, one isn't yet available. But some good progress is currently being made on it.

Thanks,

# Eric Suen (18 years ago)

Some more,

QualifiedNameIdentifier ::= '*' | OverloadedOperator | ...

But '*' already in OverloadedOperator

AttributeIdentifier not exists, should be AttributeName?

SwitchTypeStatement not be used in any other rules

ClassName be removed, but still be used in InterfaceDefinition and FunctionDefinition

ParameterisedTypeName was removed, but still be used in TypeDefinition

BTW, will the final Spec. be LR(1)?

,

# Eric Suen (18 years ago)

Some typo:

TypeParametersList ::= Identifier | Identifier , TypeParameterList

TypeParametersList should be TypeParameterList

BitwiseAndExpression[a,b] ::= EqualityExpression[a,b] | BitwiseAndExpressionr[a,b] & EqualityExpression[a,b]

BitwiseAndExpressionr should be BitwiseAndExpression

InitaliserList ::= Initialiser | InitialiserList ',' Initialiser

InitaliserList should be InitialiserList

# Jeff Dyer (18 years ago)

Updated grammar posted at (new location):

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

Thanks again for the bug reports.

Also, we have no plans to write an LR(1) grammar for ES4. I'm not even sure it is possible. Are you volunteering? :)

# Eric Suen (18 years ago)

Others: Directive[t,w] ::= EmptyStatement | Statement[w] | AnnotatableDirective[t,w]

Statement[w] should be Statement[t, w]

ForInitialiser ::= $empty | ListExpression[allowColon,noIn] | VariableDefinition[noIn]

VariableDefinition[b,w] ::= VariableDefinitionKind VariableBindingList[b] Semicolon[w]

Since VariableDefinition has Semicolon, I don't think it should be used in ForInitialiser

CaseElements ::= ... | CaseLabel CaseElementsPrefix Directive_abbrev

CaseElementsPrefix ::= ... | CaseElementsPrefix Directive_full

Directive_abbrev should be Directive_local_abbrev and Directive_full should be Directive_local_full?

AnnotatableDirective[global,w] ::= ... | FunctionDefinition[global]

AnnotatableDirective[t,w] ::= ... | FunctionDefinition[t]

FunctionDefinition[global] should be FunctionDefinition[global,w], FunctionDefinition[t] should be FunctionDefinition[t, w]

# Garrett Smith (18 years ago)

Hi,

Updated grammar posted at (new location): www.ecmascript.org/es4/spec/grammar.pdf Thanks again for the bug reports. Also, we have no plans to write an LR(1) grammar for ES4. I'm not even sure it is possible. Are you volunteering? :)

I would help out with documentation where I can.

I have read the JLS and most of the W3C docs. I find the current LR grammar of ES 3 doc to be less intuitive than these.

I'd like to see working examples that clearly exhibit the language. Ideally, examples from the tests, so that it's in-sync. I prefer examples so I can tell what works, what doesn't, and get a clear explanation right next to a working example that I can run.

I'm still learning about ES4, though. if you hand things off to me, I could write stuff up but it would need review.

Garrett

# Eric Suen (18 years ago)

23-Jul-2007: Require Block body in LetStatement

according: bugs.ecmascript.org/ticket/85

ExpressionStatement ::= [lookahead !{ function, let, { }] ListExpression[allowColon,allowIn]

Isn't that enough to tell "let (x = 10);" is LetStatement not ExpressionStatement with LetExpression?

YieldExpression ::= yield | yield AssignmentExpression

because yield is ContextuallyReservedIdentifier, so:

var yield; yield;

is this yield a Identifier or YieldExpression?

if (yield) { }

is this yield a Identifier or YieldExpression?

unit not in ReservedIdentifier or ContextuallyReservedIdentifier

FunctionDeclaration ::= function FunctionName FunctionSignature

should be

FunctionDeclaration[w] ::= function FunctionName FunctionSignature Semicolon[w]

AnnotatableDirective[global,w] ::= Attribute[t] AnnotatableDirective[global,w] | PackageDefinition | ...

PackageDefinition ::= PackageAttributes 'package' PackageNameOpt PackageBody

Attribute[t] conflict with PackageAttributes

NamespaceAttribute ::= public | Identifier | Path . Identifier | ...

Isn't Path already including them all?

Path ::= Identifier | Path . Identifier

Is there any plan when the Spec. will be form?

,

# Jeff Dyer (18 years ago)

Thanks for offering to help. The kind of help we can use most right now is the kind that Eric and others have provided with the grammar: detailed feedback on the correctness and completeness of what the working group has produced thus far. My request for volunteers was specific and, in part, tongue-in-cheek, believing that such as grammar cannot be written.

We plan to produce a (dramatically revised) early draft of the spec later this year. Your feedback on that draft will be welcomed. In the mean time any comments you have on the grammar, proposals or reference implementation will also be greatly appreciated.

BTW, I don't expect the ES4 spec to look much like the JLS. We want ES4 to be more specifically defined, not depending on a single commercial implementation to resolve ambiguities in the specification. Our audience consists of language implementers and so we favor correctness and conciseness over the ease-of-use provided by numerous working examples and flowing prose. The JLS is a funny beast in that it tries to be a language definition and a reference manual in one. This kind of worked when Java was simple, but the 3rd edition is hard to read from either the implementers or users perspective.

Thanks again for getting involved.

Jd

-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss- bounces at mozilla.org] On Behalf Of Garrett Smith Sent: Wednesday, August 22, 2007 1:12 PM To: es4-discuss at mozilla.org Subject: Some bugs of Spec.

Hi,

Updated grammar posted at (new location): www.ecmascript.org/es4/spec/grammar.pdf Thanks again for the bug reports. Also, we have no plans to write an LR(1) grammar for ES4. I'm not

even