Annex A of 5th Edition

[Joseph Spencer]

Thanks for the link!  I checked out the .doc and see what you mean.

Especially for the following cases:

1) detecting global assignment when "use strict"; has been declared
2) var a = {
     duplicate:"not allowed",
     get duplicate(){return "not allowed"},
     set duplicate(){throw "This isn't allowed"}
   }; 
etc.

Those two cases aren't covered by any BNF I've seen, and probably can't
be without introducing more logic as you've endeavored.  I see value in
getting as close as possible with plain BNF, and then adding more
algorithmic details as needed / required without making it completely
un-readable.

So yes, I think that is what I'm suggesting.  I think as we've seen with
our Chromie friends, Annex A will probably be more adhered to at times
than what is defined elsewhere in the spec (with regards to valid
syntax) as it provides a complete overview of the grammar in roughly 20
pages or so.  There does come a point where you have to delve further,
hence the @See directives on the right.

-Joe

On Fri, 2012-09-07 at 11:05 -0700, Allen Wirfs-Brock wrote:
> 
> On Sep 6, 2012, at 10:19 PM, Joseph Spencer wrote:
> 
> > Would it not be beneficial to bring Annex A into greater conformity
> > with
> > the rest of the spec at this point?  
> > 
> > Such changes seem relatively safe (to a noobie that is ;), as any
> > code
> > produced moving forward by devs would still parse just fine under
> > older
> > implementations that allowed for the unwanted syntax.  It seems that
> > doing so would also bring the ecosystem of implementations into
> > greater
> > alignment moving forward.
> > 
> > 
> 
> 
> Annex A is just a informative summary of the normative BNF that is
> scattered through-out the rest of the document, so I think what you
> are really suggesting that w try to express more of the static
> semantics using the normative grammar.  For the ES6 spec. I'm actually
> going in a different direction which is more algorithmic specification
> of the static semantic restrictions on syntactically valid programs.
>  Many of these restrictions concern non-local feature interactions
> that are difficult or impossible to express purely using a
> non-attributed BNF.  If you haven't already, you should take a look at
> the ES6
> draft http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts 
> 
> 
> Just this morning, I wrote static semantic rules that cover the
> Postfix and PrefixExpression (and other assignment contexts) that you
> had noted.
> 
> 
> Allen
> 
> 
> 
>