Block lambda grammar: BlockArguments

Axel Rauschmayer axel at
Sat Jan 14 16:58:57 PST 2012

>> If Ruby-style magic isn’t an option then I would expect (and prefer) that there were only two calling “modes”:
>> - Traditional: myfunc(arg1, arg2, ...}
>> - Paren-free – lambdas only: myfunc {|| body1} {|| body2} ...
> The objection (if you read the whole thread containing the message I cited, I think you'll find it) was that requiring *only* block-lambdas for the paren-free call form means expression arguments, even ones as simple as numeric literals, must be bracketed by {|| and }. Why not allow ( and ) instead?
> (*) One counter-argument is that this looks the argument list of a call expression whose callee is everything to the left. But paren-free call syntax supports newline termination, so I added the ... ( Initial Value ) production to satisfy setTimeout-like use cases without requiring {|| and | as brackets.
> If this alternate production bites back in some way, or is simply under-used or too surprising, I'll yank it.

Three arguments in favor of yanking:

- Thanks to lambdas, setTimeout already looks very nice – even as a parenthesized function call.

- Putting callable values last is more likely, the grammar rule introduces an odd asymmetry, by not allowing leading a leading ( InitialValue ) . I’m not saying that that would be a desirable feature (currying is fine here), just that trailing non-lambdas seem much rarer than leading non-lambdas.

- The counter-argument (*) you mention above weighs heavily. Most people (certainly me) probably expect a function or method call when they see a parenthesized value.

The following seems like an elegant and easy to understand rule to me:
    “The parameters of a function or method call are either parenthesized or paren-free. In the latter case, all parameters must be lambdas.”

Dr. Axel Rauschmayer
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list