Different semantics should have different-looking syntax

[Dmitry A. Soshnikov]

On 21.05.2011 23:37, Brendan Eich wrote:
> For http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival I have written up the Ruby-inspired {|x| x * x} syntax.
>

First, this proposal is also useful for JS. Especially the semantics of 
returning from a closure (so this is what TCP addresses, now I see that 
it's not the "Transmission Control Protocol" :D, and actually I myself 
addressed this issue long time before - http://bit.ly/eVq5ob (JFTR), 
though without mentioning Tennet's principle).

Currently we have to use try-catch to handle simple search engine with 
using e.g. `forEach` for that. So using `return` inside the 
block-closure will exit all block contexts -- as an exception would be 
thrown and caught at non-block level (i.e. at function level), right? At 
least Ruby uses such a way. And we use "return-less" return, i.e. just 
via control-flow structure, then a block return to the caller. It seems 
a good addition.

It turns out now that it's really a dilemma what to choose -- arrows or 
blocks... have to think.

Dmitry.

> 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".
>
> 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.
>
> Thus, block lambdas that start with { and have lightweight parameter delimiters.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss