block lambda revival

[Brendan Eich]

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>