Block lambda grammar: BlockArguments

Axel Rauschmayer axel at rauschma.de
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 rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120115/75ddc99c/attachment.html>


More information about the es-discuss mailing list