Question about spec

# rasmus ekman (18 years ago)

Just an arbitrary newbie question... I note that the updated UnaryExpression BNF codifies part of the behaviour of ES-262 implementations:

UnaryExpression -> PostfixExpression | delete PostfixExpression | void UnaryExpression | typeof UnaryExpression | ++ PostfixExpression | -- PostfixExpression | + UnaryExpression | - UnaryExpression (etc)

So ++++a is ruled out at syntax level, and -++a is legal while ++-a isn't. This matches (part of) behaviour of current implementations.

But is ++a++ going to become legal?

In IE ++a++ etc are reported as runtime errors. Seamonkey code goes directly to MemberExpression after matching ++/--, is this the intention? If so, why not in spec?

More generally, is there a reason for deferring to runtime if it is knowable at parse time that a construct is anyway going to be an error? (I'm thinking of detail issues like the above, but have no particular examples at hand where seamonkey defers to runtime)

Thanks,

re
# Brendan Eich (18 years ago)

On Aug 22, 2007, at 2:17 PM, rasmus ekman wrote:

Just an arbitrary newbie question... I note that the updated UnaryExpression BNF codifies part of the behaviour of ES-262 implementations:

UnaryExpression -> PostfixExpression | delete PostfixExpression | void UnaryExpression | typeof UnaryExpression | ++ PostfixExpression | -- PostfixExpression | + UnaryExpression | - UnaryExpression (etc)

So ++++a is ruled out at syntax level, and -++a is legal while ++-a
isn't. This matches (part of) behaviour of current implementations.

But is ++a++ going to become legal?

Never, provided ++a cannot result in a magic native object of some
kind (which could be an lvalue). See ECMA-262 Edition 3, Chapter 16:

An implementation may treat any instance of the following kinds of
runtime errors as a syntax error and therefore report it early: • Improper uses of return, break, and continue. • Using the eval property other than via a direct call. • Errors in regular expression literals. • Attempts to call PutValue on a value that is not a reference (for
example, executing the assignment statement 3=4). An implementation shall not report other kinds of runtime errors
early even if the compiler can prove that a construct cannot execute
without error under any circumstances. An implementation may issue an
early warning in such a case, but it should not report the error
until the relevant construct is actually executed.

In IE ++a++ etc are reported as runtime errors.

It's allowed to, per the above chapter and verse.

Seamonkey

(SpiderMonkey)

code goes directly to MemberExpression after matching ++/--, is this the intention? If so, why not in spec?

The spec intentionally under-specifies to allow for different
implementation strategies.

IMHO, the ES1-3 specs do this too much, and we are trying to improve
the situation for ES4. Note however that C, Scheme, and lots of other
languages under-specify even more aggressively. JS is different,
because interoperation across browsers and other "JS engines" is more
the rule than for other languages, which may cluster in source form
in silos where only one compiler is used. For fun, read through
Dawson Engler's www.stanford.edu/~engler/spin05-coverity.pdf
some time.