1

Let's say that at some point of a parsing process, I've already traversed the following grammar derivation:

Script -> ScriptBody -> StatementList -> ExpressionStatement -> Expression

Here comes the trouble. According to the spec, an Expression within an ExpressionStatement can only end up as an AssignmentExpression or a sequence of those. However, statements like 

a;
12;
"some text";

definitely are expression statements (as far as I understand), at the same time not being any of the AssignmentExpression's possible subtypes. They do not resolve to a syntax error in my browsers.

Is it a particular implementation's or engine's feature that these statements return the value or am I missing something in the spec? Maybe, those are not AssignmentExpressions at all and I'm mistaking them for something else?

WTEDST
  • 925
  • 5
  • 15
  • Clause 13.5 in the Syntax section: http://www.ecma-international.org/ecma-262/#sec-expression-statement links to 12.16, Comma Operator: http://www.ecma-international.org/ecma-262/#sec-comma-operator – WTEDST Sep 29 '18 at 02:33

1 Answers1

3

When you take a look at the definition of AssignmentExpression, you'll see that it resolves to , for example, AssignmentExpression -> ConditionalExpression -> LogicalORExpression -> LogicalANDExpression -> BitwiseORExpression -> BitwiseXORExpression -> BitwiseANDExpression -> EqualityExpression -> RelationalExpression -> ShiftExpression -> AdditiveExpression -> MultiplicativeExpression -> ExponentiationExpression -> UnaryExpression -> UpdateExpression -> LeftHandSideExpression -> NewExpression -> MemberExpression -> PrimaryExpression -> Literal -> StringLiteral.

So "some text" is a valid AssignmentExpression. The same goes for other literals and variable references.

snak
  • 6,483
  • 3
  • 23
  • 33