Block lambda is cool, its syntax isn't

Brendan Eich brendan at mozilla.org
Wed Jan 18 02:09:57 PST 2012


Yes, we've been over many prefixes, from Greek lowercase lambda to \ to 
^. Two problems, one specific to ^, the other general to the body plan 
you propose:

1. ^ is taken as the bitwise XOR operator. So there's an "ASI didn't 
happen but the user expected it" hazard motivating us to restrict any 
operand (vs. operator) context overloading of ^ to start a lambda to 
have [no LineTerminator here] on the left of the operand-^. Otherwise 
valid JS of the form

   x = y
   ^{z: w}

is too easily confused for an assignment expression statement 
(terminated by an automatically inserted semicolon, the mistaken reader 
thinks -- there could be comments and lots of blank lines between the 
two lines shown above) followed by a lambda.

Even with the above being forbidden by [no LineTerminator here] to the 
left of the lambda' productions right hand side, allowing x ^ ^{y} 
smells bad. But perhaps not as bad as pipes on the inside -- YMMV.

2. The TCP conformance makes anything like function (params) {body} an 
anti-pattern. Changing function to ^ does not avoid this problem. We 
want block-lambdas to look different from functions.

(2) is an overriding objection in my view.

/be

> Gavin Barraclough <mailto:barraclough at apple.com>
> January 18, 2012 1:28 AM
> Just a thought, has a prefix ^ been considered?
>
> A lambda that takes no arguments could be:
> ^{ /*...*/ }
> And a lambda with some arguments:
> ^(x,y){ /*...*/ }
>
> I just find this really readable, the syntax for lambdas that take no 
> arguments is delightfully minimal (just one extra character!), my 
> brain is well trained to expect argument lists to be delimited by 
> parentheses so I find this much easier to understand, and I find the ^ 
> character pleasingly evocative of λ. :-)
>
> cheers,
> G.
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Brendan Eich <mailto:brendan at mozilla.org>
> January 13, 2012 3:03 PM
> The { and } around the || make it pretty clear the || is not a 
> boolean. Also  you can put a space in {| |}. But mainly, as with any 
> alternative bracketing system that uses an infix operator, we are 
> relying on the leading { to make it clear that the immediately 
> following delimiter, | in the proposal, cannot represent its usual 
> infix role (| or ||).
>
> /be
>
> john saylor <mailto:js0000 at gmail.com>
> January 13, 2012 1:11 PM
>
>
> yes, i had the same impression [thx to those who supplied code examples].
>
> one problem i came across in this domain is that a block lambda with 
> no arguments is visually identical to a boolean or ['||']. context, i 
> believe, will clarify this; but from a purely visual perspective, two 
> adjacent pipe characters are almost archetypal for the boolean or 
> operator [if i can speak about archetypes in computer programming].
>
> Rick Waldron <mailto:waldron.rick at gmail.com>
> January 13, 2012 12:36 PM
> FWIW, After working through the example gists that I created last 
> night, my opinion changed about the look of Block Lambda's with pipes. 
> As others on the list have said previously and is now very clear to 
> me, pipes provide a very distinct visual cue "this is a block lambda, 
> expect X to happen here" where the {(args) expr } gets lost; these 
> visual cues are important when you're reading and writing "real world" 
> programs in JavaScript.
>
>
> Rick
>
>
>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> January 13, 2012 10:51 AM
>
>
>
> I've updated a version of my ES.next Smalltalk collections 
> implementation experiment to use block lambdas.
> This version is 
> https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.js 
>
> The one that you should compare it to is 
> https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.js 
>
>
> As you might expect, this new version is even closer in form to the 
> original Smalltalk code.
> In particularly, I was able to eliminate all the artifacts that needed 
> to be introduced because of function expressions  don't have Tennent's 
> Correspondence.
> In the source, I've tagged the lines where TCP is using /*TCP*/
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120118/7776a314/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120118/7776a314/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1290 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120118/7776a314/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1716 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120118/7776a314/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1265 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120118/7776a314/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1287 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120118/7776a314/attachment-0009.jpg>


More information about the es-discuss mailing list