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