January 13, 2012 9:09 PM

If I read the grammar correctly, then you can do things such as (read "~~~>" as "desugars to"):

     myfunc {|| } {|| } (arg3) (arg4)  ~~~>  myfunc({|| }, {|| }, arg3, arg4)

The above is a function call with 4 arguments. My wish would be different: I would want to put lambdas after a function or method call and treat those lambdas as additional arguments:

     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.

Rationale: I would always make lambdas trailing arguments, similar to
     if (cond) {} {}
And I would rather achieve this effect without currying.

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

Your use-case is satisfied by returning a function (memoized, singleton even), but the symmetry between (arg1, ... argN) and space-separated BlockArguments should not be broken.

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.

Has the other approach been considered?

Yes, see

https://mail.mozilla.org/pipermail/es-discuss/2011-May/014675.html

/be

-- 
Dr. Axel Rauschmayer


January 13, 2012 12:58 PM
Fixed: http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival&do=diff

The LeftHandSideExpression productions and their kids (NewExpression and CallExpression) are funky and I keep misremembering how NewExpression is what bottoms out via MemberExpression -> PrimaryExpression at Identifier.

/be

January 12, 2012 11:43 PM
January 12, 2012 11:39 PM
  v.map {|e| e*e}

Er, not even that -- Arguments required in a CallExpression, so v().map or v.map() but not just v.map. Fixes coming tomorrow.

/be

or

  get_map() {|e| e*e}

or similar. I will fix.

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
January 12, 2012 11:16 PM
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival

I’m

 trying to understand the syntax:
BlockArguments :
BlockLambda
BlockArguments [no LineTerminator here] BlockLambda
BlockArguments [no LineTerminator here] ( InitialValue )

- Wouldn’t this allow the following? BlockLambda [no LineTerminator here] BlockLambda
- InitialValue means that paren-free can be combined with arguments that aren’t blocks, right?

myLoopFunc(initValue1)(initValue2) { | arg1, arg2 | ... }

I think I would prefer the following (IIRC, more like Ruby):

myLoopFunc(initValue1, initValue2) { | arg1, arg2 | ... }



January 12, 2012 11:39 PM
January 12, 2012 11:16 PM
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival

I’m trying to understand the syntax:
BlockArguments :
     BlockLambda
     BlockArguments [no LineTerminator here] BlockLambda
     BlockArguments [no LineTerminator here] ( InitialValue )

- Wouldn’t this allow the following? BlockLambda [no LineTerminator here] BlockLambda

Yes.

- InitialValue means that paren-free can be combined with arguments that aren’t blocks, right?

Yes.

myLoopFunc(initValue1)(initValue2) { | arg1, arg2 | ... }

No, the myLoopFunc(initValue1) is a CallExpression -- see
CallWithBlockArguments :
    CallExpression [no LineTerminator here] BlockArguments
  The *return value* of that ordinary CallExpression is the callee of the paren-free call.

I think I would prefer the following (IIRC, more like Ruby):

myLoopFunc(initValue1, initValue2) { | arg1, arg2 | ... }


That parses, as described above. The two-argument CallExpression must return a function that takes the block arguments.

I see a problem in the grammar in the strawman, now that you mention it: no way to produce a simple identifier callee from CallExpression, so no

  map {|e| e*e}

only

  v.map {|e| e*e}

or

  get_map() {|e| e*e}

or similar. I will fix.

/be
January 12, 2012 11:16 PM
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival

I’m trying to understand the syntax:
BlockArguments :
BlockLambda
BlockArguments [no LineTerminator here] BlockLambda
BlockArguments [no LineTerminator here] ( InitialValue )

- Wouldn’t this allow the following? BlockLambda [no LineTerminator here] BlockLambda
- InitialValue means that paren-free can be combined with arguments that aren’t blocks, right?

myLoopFunc(initValue1)(initValue2) { | arg1, arg2 | ... }

I think I would prefer the following (IIRC, more like Ruby):

myLoopFunc(initValue1, initValue2) { | arg1, arg2 | ... }



_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to