statements that could be expressions?

Kam Kasravi kamkasravi at
Sat Jun 4 20:21:38 PDT 2011

The latest narcissus has a few strawmen incorporated.
Narcissus is very cool and easy to understand (most of it anyway), 
though its not auto-generated from any type of BNF grammar. Pegjs does 
autogenerate from a slightly annotated BNF (see javascript.pegjs under examples 
on github) though it does not transpile to any target backend like es5.
There may be others out there that would make your life easier eg traceur or ometa.
Just FYI.

From: Breton Slivka <zen at>
To: Brendan Eich <brendan at>
Cc: es-discuss <es-discuss at>
Sent: Saturday, June 4, 2011 7:12 PM
Subject: Re: statements that could be expressions?

If I could demonstrate my idea working in Narcissus (or your parser of
choice), would that be helpful or useful to anyone?

I was thinking about the ambiguity of {x,y} with relation to the
key/value shortcut, and it seems that there's a lot of ambiguities
around the { symbol that are causing some problems. My idea basically
boils down to embracing the ambiguities as special cases of the same
underlying semantic structure.

To put this another way, this is my thought exercise: pretend that
we're scientifically observing the state of javascript today, and we
decided to operate under the assumption that *all* structures that
begin with { and end with } compile and evaluate into the same type of
semantic structure (instead of multiple different kinds, function
bodies, objects, blocks with labels, and what have you) what kind of
structure is it that we are observing? It would seem like that as the
language stands we get access to a subset of this structure's
capabilities. In terms of moving forward, what kind of properties can
we extrapolate from what we know about this structure type already?
Looking backwards, what sort of properties does this structure have
currently that would produce the behaviour we see today?

There needs to be a lot more practical work done on this idea to make
it particularly compelling, but as I said, I'm willing to tinker with
getting it working in an existing javascript parser/evaluator if
anyone on this list thinks it is worth the time to investigate.

On Sat, Jun 4, 2011 at 9:04 AM, Brendan Eich <brendan at> wrote:
> On Jun 3, 2011, at 3:11 PM, Waldemar Horwat wrote:
>> On 06/02/11 20:12, Brendan Eich wrote:
>>>> - Conflict between blocks and statements:
>>>> a = {x: while (x) { ... break x;}}
>>>> is either an object initializer or a block containing a labeled while statement.
>>> based on feedback from Jorge here on the list mentions a block that cannot start with a label. Two-token lookahead restriction, why not?
>> Don't you also want to allow (either now or in the future) for the shorthand {x, y} to mean {x:x, y:y}?  There are also getters, setters, and various other stuff that can be put into object initializers now or in the future, so there are more possibilities than just an identifier followed by a colon.
> True, and {x, y} is noted somewhere (or was in a past version) as a problem. did not get promoted yet, and I forgot to keep this pot boiling.
> The accessors are not ambiguous, but the proposed !, ~, and # property prefixes for writable, enumerable, and configurable false-setting do make trouble.
> Perhaps Breton's more radical idea of unifying objects and block (lambdas) deserves a look, instead of trying to separate syntaxes that start with { at this late date.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at
es-discuss mailing list
es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list