Ambiguity for 'Program' in ES3.1 grammar (was: Allowing for stricter subsets in future versions)
david.hopwood at industrial-designers.co.uk
Mon Oct 27 21:52:22 PDT 2008
Mark S. Miller wrote:
> On Mon, Oct 27, 2008 at 7:11 PM, David-Sarah Hopwood
> <david.hopwood at industrial-designers.co.uk> wrote:
>> [...] The redundancy can be avoided by specifying,
>> in ES3.1, that the strict literal that turns on strict mode only needs
>> to *start* with "use strict". [...]
> In Redmond we adopted essentially this same idea, but with comma as
> the separator.
OK, I must have been looking at a draft earlier than Redmond.
I notice that the grammar given in section 14 is ambiguous:
since a UseSubsetDirective also matches Statement, and there is no "greedy"
rule saying that the UseSubsetDirective_opt must be consumed if it is
possible to do so. (The lexical grammar has such a rule; the syntactic
grammar doesn't.) If we were using a grammar formalism with a prioritized
choice operator '/', it would be:
but we aren't. (Personally I think prioritized choice is both clearer,
and more easily expressible in commonly used parser-generation languages
than negative lookahead; note that the other uses of negative lookahead
in the ES3 spec are also easily expressed using prioritized choice. But
there is some advantage to sticking with the same formalism as ES3.)
I hesitate to suggest using "[lookahead \notin UseSubsetDirective]",
though, since lookahead is only used for single tokens elsewhere, and a
UseSubsetDirective is two tokens. "[lookahead \notin StringLiteral]"
would be incorrect, since that would ignore a first statement such as:
"foo" + side_effects();
It might be simpler to just use
and then say that the first SourceElement is treated as a UseSubsetDirective
if it can be parsed as one.
Also, shouldn't it be SourceElements_opt? There's no reason to reject an
More information about the Es-discuss