block lambda revival
Brendan Eich
brendan at mozilla.com
Mon May 23 18:09:01 PDT 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110523/751201da/attachment.html>
More information about the es-discuss
mailing list