>> 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
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
