Rule 317

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Rule 317

David Teller-3
    Hello list,

 I'm still fighting the syntax of JS2. Attempting to feed it into a
parser generator (menhir, for the moment), has already allowed me to
find a few typoes in the spec and a few useless variables in the
reference implementation, which is all I have to show for the moment.
That and the fact that all XML* productions seem absent from the RI.

At the moment, though, I'm being puzzled by rule 317:

ExpressionStatement
|  ListExpression (allowColon, allowIn)
   [if lookahead not in { "function", "let", "{" }]

Besides the fact that this rule is annoying to implement, does it
actually mean what it intends ? In addition to blocks, it also prevents
an assignment to an object pattern from starting the ListExpression. Is
that desired ?

Thanks,
 David

P.S.:
 I forgot where I found that version of the grammar, it's dated
14/10/2007, so I assume it's the latest. Where are they to be found, in
general ?

--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
Project JStify: Static Analysis for JavaScript 2  -----
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rule 317

liorean
On 23/10/2007, David Teller <[hidden email]> wrote:

>     Hello list,
>
>  I'm still fighting the syntax of JS2. Attempting to feed it into a
> parser generator (menhir, for the moment), has already allowed me to
> find a few typoes in the spec and a few useless variables in the
> reference implementation, which is all I have to show for the moment.
> That and the fact that all XML* productions seem absent from the RI.
>
> At the moment, though, I'm being puzzled by rule 317:
>
> ExpressionStatement
> |  ListExpression (allowColon, allowIn)
>    [if lookahead not in { "function", "let", "{" }]
>
> Besides the fact that this rule is annoying to implement, does it
> actually mean what it intends ? In addition to blocks, it also prevents
> an assignment to an object pattern from starting the ListExpression. Is
> that desired ?

It's there to prevent the grammar from being ambiguous. "function",
"let" and "{" have different meaning in statement context from
expression context. If the ExpressionStatement construct allowed them,
then they would be ambigous in statement context, they could have
either the statement or the expression semantics. So, in order to
prevent this ambiguity, they are not allowed in ExpressionStatement.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Rule 317

Jeff Dyer
In reply to this post by David Teller-3

> -----Original Message-----
> From: [hidden email] [mailto:es4-discuss-
> [hidden email]] On Behalf Of David Teller
> Sent: Tuesday, October 23, 2007 4:11 AM
> To: JS2
> Subject: Rule 317
>
>     Hello list,
>
>  I'm still fighting the syntax of JS2. Attempting to feed it into a
> parser generator (menhir, for the moment), has already allowed me to
> find a few typoes in the spec and a few useless variables in the
> reference implementation, which is all I have to show for the moment.
> That and the fact that all XML* productions seem absent from the RI.

Correct. It is reserved syntax that is TBD.

> P.S.:
>  I forgot where I found that version of the grammar, it's dated
> 14/10/2007, so I assume it's the latest. Where are they to be found,
in
> general ?

We keep an .xls file in the ./doc directory of the RI. You can find the
latest there.

Jd
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rule 317

David Teller-3
In reply to this post by liorean
On Tue, 2007-10-23 at 14:58 +0200, liorean wrote:
> It's there to prevent the grammar from being ambiguous. "function",
> "let" and "{" have different meaning in statement context from
> expression context. If the ExpressionStatement construct allowed them,
> then they would be ambigous in statement context, they could have
> either the statement or the expression semantics. So, in order to
> prevent this ambiguity, they are not allowed in ExpressionStatement.

So I guess this could just be handled by making this rule have a lowest
priority ?


Cheers,
 David

--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
Project JStify: Static Analysis for JavaScript 2  -----
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rule 317

liorean
> On Tue, 2007-10-23 at 14:58 +0200, liorean wrote:
> > It's there to prevent the grammar from being ambiguous. "function",
> > "let" and "{" have different meaning in statement context from
> > expression context. If the ExpressionStatement construct allowed them,
> > then they would be ambigous in statement context, they could have
> > either the statement or the expression semantics. So, in order to
> > prevent this ambiguity, they are not allowed in ExpressionStatement.

On 23/10/2007, David Teller <[hidden email]> wrote:
> So I guess this could just be handled by making this rule have a lowest
> priority ?

Not really. In statement context, a function without a name should be
a syntax error, it shouldn't be handled as function expression because
that'd be pointless. If the function object is only accessible through
the return value of the function expression but it's in statement
context - i.e. return values are thrown away - then compiling the
function at all is totally pointless, you're just adding a
non-reachable object for the garbage collector to deal with. In a
statement context, "{" is a block opener and not the beginning of an
object literal. In a block statement "Identifier :" is a label
statement and not a property assignment. "*string* :" is a syntax
error because ":" is not a valid operator there. (Not sure how type
annotations play into this, I might be wrong here...)

So you see, they can't just be lowest priority. They must fail with a
syntax error. For ES3 compatibility's sake, if nothing else. Also,
it's better to not let nonsensical constructs be allowed.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rule 317

David Teller-3
Ok, I think I'm now understanding something that I had completely missed
about that syntax: it's LR(1). I was assuming it was something much more
complicated with unlimited backtracking.

Dumping my code and restarting the parser with lighter tools...

Thanks and cheers,
 David

On Tue, 2007-10-23 at 19:20 +0200, liorean wrote:
> On 23/10/2007, David Teller <[hidden email]> wrote:
> > So I guess this could just be handled by making this rule have a lowest
> > priority ?
>
> Not really. In statement context, a function without a name should be
> a syntax error

--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
Project JStify: Static Analysis for JavaScript 2  -----
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss