Block lambda is cool, its syntax isn't

Brendan Eich brendan at mozilla.org
Fri Jan 13 10:24:40 PST 2012


Arrows are not a live proposal because TC39 wants to keep LR(1) parsing 
for grammar validation (checking for ambiguities). We do not have 
consensus to change and there's no champion working on a credible 
alternative.

I could have dredged them up but they really are not happening, whereas 
we have recurring and live proposals for the three body-plans I listed.

/be

> Sam Ruby <mailto:rubys at intertwingly.net>
> January 13, 2012 3:30 AM
> On Fri, Jan 13, 2012 at 12:20 AM, Brendan Eich<brendan at mozilla.org>  wrote:
>> We have three coarse-grained alternatives:
>
> If you are going to enumerate all potential alternatives (including
> ones that you need to be rejected for one reason or another), then a
> CoffeeScript inspired syntax should be included:
>
>    (params) ->  {body}
>
> - Sam Ruby
>
>> 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 precedent in 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
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> 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/96dbd492/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1327 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120113/96dbd492/attachment.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/96dbd492/attachment-0001.jpg>


More information about the es-discuss mailing list