Block lambda is cool, its syntax isn't

[Brendan Eich]

> Quildreen Motta <mailto:quildreen at gmail.com>
> January 13, 2012 5:30 AM
> Given those above, despite my usual disliking of Ruby syntax, I prefer
> the pipes over parenthesis, given the latter has an already too
> overloaded semantics, such that `{ (foo, bar) (2) }' would look pretty
> confusing, at least to me. However, what about `{x, y: body}'?

Parameters have optional guards (in the future), default value 
initialisers, destructuring patterns and so on. Using : is no good 
because, while we might manage to keep the grammar unambiguous, it is 
too visually light and is not a close-bracket. It's already used in ?: 
and labels.

> Granted
> we don't allow labels immediately following a lambda block (and I'm
> not sure labels are used much in the language, I could be wrong
> however).

Consider { x, y=a?b:c : body }.

/be
>
> Brendan Eich <mailto:brendan at mozilla.org>
> January 12, 2012 9:20 PM
> We have three coarse-grained alternatives:
>
> 1. λ (params) { body }
>
> 1a. One problem is what should we use for λ? 'lambda', 'block', etc. 
> are not reserved the syntax. Whatever the identifier (including Greek 
> lambda: λ), this is an incompatible change.
>
> 1b. Another problem: this form looks like a function expression with a 
> different introductory keyword, but Tennent's Correspondence Principle 
> makes the meaning of body elements including |this| and 
> return/break/continue radically different. Different-enough semantics 
> should have different syntax.
>
> 2. { (params) body }
>
> Putting the parameter list in parentheses is more consistent with 
> function syntax, while putting the parameters on the inside stresses 
> the block-ness over function-ness. By block-ness I mean (ignoring let, 
> const, and function in Harmony) how code and {code} are equivalent.
>
> Of course this cuts against the syntax too: block statements are not 
> first-class callables whose code bodies are evaluated only if invoked, 
> they are statements evaluated eagerly when reached. This syntax is 
> arguably too block-like.
>
> A point that I remember having come up in past TC39 meetings: if we 
> ever want structuring forms (object literals or destructuring 
> patterns) that use () for grouping property names, this syntax is 
> future hostile.
>
> 3. { |params| body }
>
> This is new-to-JS, idiomatic block-like -- but not too 
> block-statement-like -- syntax for novel body semantics.
>
> The bars will drive some people to distraction. Others will grok, or 
> already do via Ruby. This is not to favor Ruby, just to build on the 
> belief that some precedentin language design is better than none.
>
> We could reject (3) in favor of (2) if we had an overriding 
> non-aesthetic reason. I don't see one.
>
> Aesthetics vary. The more conventional look of (2) seems like a 
> usability hazard to me, which trumps aesthetics. Again I'd rather have 
> something more different-looking to signal the novel application of TCP.
>
> /be
>
> Brendan Eich <mailto:brendan at mozilla.org>
> January 12, 2012 7:23 PM
> Sigh. Never mind, I'm thinking of statement not expression context -- 
> and you can't start an expression statement with {. Parade's back on. :-)
>
> /be
>
> Brendan Eich <mailto:brendan at mozilla.org>
> January 12, 2012 7:21 PM
> Sorry, thought about it more and I'm raining on your (and dherman's) 
> parade :-(.
>
> In an expression but not statement context,
>
>   ... { (x) e; }
>
> is already a valid JS program if e begins with (, [, +, or - (the last 
> two intended as unary operators but becoming binary).
>
> Note that | bracketing avoids this problem. In no case can JS of any 
> extant version have a legal sequence {|.
>
> But because {( is already allowed, what comes after the closing ) can 
> be the continuation of a parenthesized expression.
>
> Even if you don't buy my "better to look different because not 
> function" argument, this tilts the balance.
>
> /be
> Brendan Eich <mailto:brendan at mozilla.org>
> January 12, 2012 4:53 PM
> ... continuing with my sent-too-soon message:
>
>    function() {
>        asyncAction(..., { (a, b) a.add(b); } }
>    }
>
> You're right, this could be done. Allen's right that aesthetics 
> matter, and so (aesthetic sensibilities in various people were formed 
> by these) do older languages. Ruby uses || not (). Smalltalk uses | 
> but differently, and of course does not use {}.
>
> Apart from aesthetics, I argue that || are better because they are 
> different from the overloaded () pair, which mean expression grouping 
> in the nearby context of the body of the block-lambda, e.g. a.add()b; 
> above. () also are used around formal parameter lists. And of course 
> they are used for control structure heads, e.g. if (foo).
>
> Rather than overloading () yet again, for a different formal parameter 
> list context (block-lambda parameter list after {), which is 
> immediately adjacent to an expression-statement contexts (the 
> block-lambda body), I believe we should use ||.
>
> The Ruby precedent is another reason, and a particular reason to use | 
> instead of some other candidate. But I'm mainly trying to persuade you 
> here that () is not the best choice just because it brackets formal 
> parameter lists for functions.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120113/4cbffe22/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1103 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120113/4cbffe22/attachment-0002.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/20120113/4cbffe22/attachment-0003.jpg>