Block lambda grammar: BlockArguments

Axel Rauschmayer axel at rauschma.de
Sat Jan 14 13:32:00 PST 2012


>>       myfunc(arg1, arg2) {|| } {|| }  ~~~>  myfunc(arg1, arg2, {|| }, {|| })
>>      myfunc {|| } {|| }  ~~~>  myfunc({|| }, {|| })
> 
> The closing parenthesis after arg2 really ought to mean end of formal parameter list. Anything else is too magical.

I think that’s how Ruby does it. I’m on the fence. It is indeed quite magical (and not the good kind of magical).

> Why should foo(arg1)(arg2) and foo(arg1){||arg2} differ?

BlockArguments :
    BlockLambda
    BlockArguments [no LineTerminator here] BlockLambda
    BlockArguments [no LineTerminator here] ( InitialValue )

I still don’t fully understand the ( InitialValue ) at the end – it’s a single value in parens that can come after several blocks. 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} ...

>> Following a block with a non-block doesn’t seem like a good idea.
> This was an explicit goal, in order to support use-cases including setTimeout and promises APIs.

With the above I meant: In paren-free mode, following a block with a non-block doesn’t seem like a good idea. With a normal paren call, I don’t see any problems.

-- 
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/20120114/8b6dc1cb/attachment.html>


More information about the es-discuss mailing list