Different semantics should have different-looking syntax

Brendan Eich brendan at mozilla.com
Sat Jun 4 19:36:19 PDT 2011


On Jun 4, 2011, at 7:24 PM, Peter Michaux wrote:

> On Sat, May 21, 2011 at 12:37 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> For http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival I have written up the Ruby-inspired {|x| x * x} syntax.
>> 
>> Alternatives (ignoring keyword issues) that look more like function syntax (Peter's suggestion of lambda (x) { x * x }, e.g.) seem worse in this light: block lambdas do follow the correspondence principle, which is novel to JS with its C statements for control effects heritage.
>> 
>> In this light, the use of | | to bracket formal parameters seems better than anything using (...) {...}. This is not an overriding concern, but it seems worth mentioning. We want block-lambdas or any such TCP-pure new thing to have syntax that says "look! something new here".
> 
> I don't think this idea of needing different syntax for different
> semantics is a strong point in favour of the {||} syntax. ECMAScript
> programmers are already accustomed to the keyword(){} syntax template
> and have *no* trouble understanding the difference between the
> following two bits of code and what return means in each.
> 
>    if(a){return a;}
> 
>    function(a){return a;}

Yes, but if you give them

    lambda(a){return a;}

and tell them that, when that lambda is invoked, the 'return a;' returns from the outer function (if active) or throws, many will have an OMGbad reaction.

I kid you not.

Now it may be that the same cohort reacts just as badly to

    {|a| return a; }

I know at least a few people who did react badly to the former, and do not react badly to the latter -- precisely because the latter looks like a block.

But who knows? We're trading anecdotes and assertions.

The big problem for anyone who wants TCP-conformant lambdas, whatever the syntax, is the anti-TCP cohort.


>> And, since the strawman builds on block syntax, we want the new form to have syntax that "looks like a block", in which you'd expect TCP purity for break, continue, return, |this|, and arguments.
> 
> Lambdas are useful for more than just blocks in control structures. I
> don't think that use should be the sole force behind choosing the
> syntax.

You have it backward. The problem last time was that syntax too much like function, with violently different return/break/continue/this semantics, caused consternation. Such semantics cause no problem in blocks. Wherefore, block-lambdas.

This does not mean everyone (definitely you are an exception) objects to TCP.

It does mean that we are not going to standardize function-looking lambdas with TCP conformance. Whether we can standardize *anything* with TCP conformance remains to be seen.

/be


More information about the es-discuss mailing list