block lambda revival
waldemar at google.com
Mon May 23 17:43:00 PDT 2011
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.
More information about the es-discuss