block lambda revival
Waldemar Horwat
waldemar at google.com
Mon May 23 18:27:07 PDT 2011
On 05/23/11 18:09, Brendan Eich wrote:
> On May 23, 2011, at 5:43 PM, Waldemar Horwat wrote:
>
>> 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.
>
> Here are some ideas:
>
> 1. Extend the current proposal to allow parenthesized expressions interleaved with no line terminators, only optional horizontal space characters, with block-lambda expressions:
>
> bar = foo {|x| x * x} (42);
That might work, with the key part being "interleaved". We need to keep the semantics of
bar = foo(42)(33);
the same as now.
> This avoids the "currying hazard" you cited, without (I hope) introducing other hazards. If someone wants to pass an expression as an argument, then parenthesize and comma-separate all the arguments.
>
> 2. Parse as proposed but with the restriction that the last block-lambda argument "ends the line", and also parse a mixture of block-lambda expressions and assignment-expressions separated by commas. IOW, parse both
>
> bar = foo {|x| x * x} {| | 42}
Requiring that an expression end the line is nasty. You often want to use them in || or ?: operators.
> bar = foo {|x| x * x}, 42;
Without significant surgery of nearly the entire expression stack in the grammar, this one would be ambiguous with:
(bar = foo {|x| x * x}), 42
Perl has this kind of function call syntax, and every so often it will parse in a way I didn't anticipate. Things get really weird when you nest function calls.
Waldemar
More information about the es-discuss
mailing list