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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
