On 05/23/11 17:26, Brendan Eich wrote:
On May 23, 2011, at 5:12 PM, Waldemar Horwat wrote:
On 05/23/11 16:20, Brendan Eich wrote:
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
(we've yet to have a coherent discussion about what really can go into these
parameter lists).
I gave the grammar with semantics -- did you read it?
Yes. However I don't think it'd be tenable to not support rest parameters or
whatever normal functions can do.
I didn't include rest parameters (noted in the Notes) and I only tried to
include parameter default values and destructuring in the syntax, and neither
of those the semantics. Until this strawman is accepted into Harmony, it
doesn't seem worth the effort. If you are warm to it, though, I'd be glad to
overengineer it for success ;-).
I'll add a note that BlockParameterList is meant to be like FormalParameterList
but with the necessary restriction that the default value be a
BitwiseXorExpression.
I agree this aspect is fine as a first cut.
The space-separated block-lambda argument list can consist *only* of
block-lambda expressions.
That was the problem I was pointing out.
I see what you mean, but is it really a problem without user testing? I could
try to make it an error but that seems unnecessary at this stage. Unless you
have a simple fix in mind?
I don't have a simple fix in mind. What's making me dubious about this is that
this is a function calling syntax that can supply a bunch of literal functions
as arguments, but they must all be literal functions. As soon as you want to
pass a function held in a variable or pass an argument that's not a function,
you can't use the syntax any more. And if you forget to insert a comma between
literal functions when refactoring to the regular syntax, you'll silently get
an unexpected behavior.
Waldemar
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
