Arrow function syntax cover syntax
On Apr 7, 2012, at 1:40 PM, Erik Arvidsson wrote:
This does not work for rest parameter since ... is only allowed inside array literals.
var tail = (x, ...xs) => xs;
This can of course be solved in numerous ways but it is not true that the Expression is a cover grammar for FormalParameterList.
Another option is to allow ...expression in an expression which would have the same semantics as a comma expression where the expression has been spread:
Or allow it in the grammar and then disallow it in the post-processing. IOW, a cover grammar doesn't have to force us to introduce new syntactic forms, they just force us to put them in the grammar. The post-processing, which essentially defines the two sub-grammars for the two separate contexts, can remove the syntactic forms we don't want to provide semantics for.
On Mon, Apr 9, 2012 at 5:05 PM, David Herman <dherman at mozilla.com> wrote:
On Apr 7, 2012, at 1:40 PM, Erik Arvidsson wrote:
This does not work for rest parameter since ... is only allowed inside array literals.
var tail = (x, ...xs) => xs;
This can of course be solved in numerous ways but it is not true that the Expression is a cover grammar for FormalParameterList.
Another option is to allow ...expression in an expression which would have the same semantics as a comma expression where the expression has been spread:
Or allow it in the grammar and then disallow it in the post-processing. IOW, a cover grammar doesn't have to force us to introduce new syntactic forms, they just force us to put them in the grammar. The post-processing, which essentially defines the two sub-grammars for the two separate contexts, can remove the syntactic forms we don't want to provide semantics for.
Hmm...a deviously simple solution, and yet - it feels so wrong. Grammatically legal and yet illegal. I sense complaints by implementors. :)
Russell Leggett wrote:
Or allow it in the grammar and then disallow it in the post-processing. IOW, a cover grammar doesn't have to force us to introduce new syntactic forms, they just force us to put them in the *grammar*. The post-processing, which essentially defines the two sub-grammars for the two separate contexts, can remove the syntactic forms we don't want to provide semantics for.Hmm...a deviously simple solution, and yet - it feels so wrong. Grammatically legal and yet illegal. I sense complaints by implementors. :)
Implementors all (AFAIK) use top-down parsers that have no problem implementing left-hand-side expressions without reifying Reference types, that is by validating a parse tree and throwing early errors on illegal LHS of assignment, ++, etc.
There's still a smell if the cover grammar covers too much, but I think '...' is tolerable. Thanks, Arv, for pointing this out.
strawman:arrow_function_syntax
"This works because Expression is a cover grammar for FormalParameterList, with Identifier primary expressions covering formal parameter names, array and object literals for destructuring, assignment for parameter default values, and spread for rest parameters."
This does not work for rest parameter since ... is only allowed inside array literals.
var tail = (x, ...xs) => xs;
This can of course be solved in numerous ways but it is not true that the Expression is a cover grammar for FormalParameterList.
Another option is to allow ...expression in an expression which would have the same semantics as a comma expression where the expression has been spread:
...expression
desugars to
var $tmp = expression; ($tmp[0], $tmp[1], ..., $tmp[$tmp.length - 1])
but that is kind of useless.