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:
Program :
UseSubsetDirective SourceElements
/ SourceElements
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
Program :
SourceElements
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
empty program.
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:
Program :
UseSubsetDirective_opt SourceElements
SourceElements:
SourceElement
SourceElements SourceElement
SourceElement:
Statement
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:
Program :
UseSubsetDirective SourceElements
/ SourceElements
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
Program :
SourceElements
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
empty program.
--
David-Sarah Hopwood
Mark S. Miller wrote:
OK, I must have been looking at a draft earlier than Redmond.
I notice that the grammar given in section 14 is ambiguous:
Program : UseSubsetDirective_opt SourceElements
SourceElements: SourceElement SourceElements SourceElement
SourceElement: Statement
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:
Program : UseSubsetDirective SourceElements / SourceElements
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
Program : SourceElements
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 empty program.
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: Program : UseSubsetDirective_opt SourceElements SourceElements: SourceElement SourceElements SourceElement SourceElement: Statement 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: Program : UseSubsetDirective SourceElements / SourceElements 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 Program : SourceElements 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 empty program. -- David-Sarah Hopwood