> On 30 Nov 2016, at 19:54, Simon Richter wrote:
> I have a grammar for ECMAScript, ...
You might check in the Usenet newsgroup comp.compilers if somebody has done it
before.
> ...which has both brace delimited statement
> blocks and brace delimited object literals, and allows expressions to
> On 30 Nov 2016, at 22:40, Simon Richter wrote:
>
>>> %token IF "if"
>>> %token ELSE "else"
>
>> This can be resolved by adding
>> %nonassoc "then"
>> %nonassoc "else"
>
> Yes, that is what I'm doing, except that I need to give a precedence to
> the closing parenthesis because there is no e
Hi,
On 30.11.2016 22:36, Hans Åberg wrote:
>> %token IF "if"
>> %token ELSE "else"
> This can be resolved by adding
> %nonassoc "then"
> %nonassoc "else"
Yes, that is what I'm doing, except that I need to give a precedence to
the closing parenthesis because there is no explicit "then" keywo
> On 30 Nov 2016, at 19:54, Simon Richter wrote:
>
> Likewise, I'd like to resolve the dangling-else problem more locally:
>
> %token IF "if"
> %token ELSE "else"
>
This can be resolved by adding
%nonassoc "then"
%nonassoc "else"
A more local solution has been discussed, at least.
___
Hi,
I have a grammar for ECMAScript, which has both brace delimited statement
blocks and brace delimited object literals, and allows expressions to be
used as statements, which creates conflicting interpretations for "{ }" as
either an empty block or an empty object.
The specification clarifies t
