On Jun 4, 2011, at 7:24 PM, Peter Michaux wrote:
> On Sat, May 21, 2011 at 12:37 PM, Brendan Eich <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
