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);
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}
and
bar = foo {|x| x * x}, 42;
/be_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
