block lambda revival

Brendan Eich brendan at mozilla.com
Mon May 23 18:29:58 PDT 2011


On May 23, 2011, at 6:27 PM, Waldemar Horwat wrote:

> On 05/23/11 18:09, Brendan Eich wrote:
>> 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.

Absolutely.

I'll make an attempt, since option 0 (see later mail) is both easy and a bit of a hasty surrender.


>> 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.

You'd have to parenthesize the whole argument list, comma separated, in such cases.


>> 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.

I have felt that weirdness myself.

Ok, I will focus on option 1. Thanks,

/be


More information about the es-discuss mailing list