block lambda revival

[Waldemar Horwat]

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