Block lambda is cool, its syntax isn't

Brendan Eich brendan at mozilla.org
Thu Jan 12 19:23:51 PST 2012


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
> _______________________________________________
> 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 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
>
> Brendan Eich <mailto:brendan at mozilla.org>
> January 12, 2012 2:49 PM
>
>> François REMY <mailto:fremycompany_pub at yahoo.fr>
>> January 12, 2012 2:23 PM
>> Am I wrong if I say there not a bigger issue with block lambda than 
>> with the current object notation on the matter?
>
> Please continue :-).
>>
>> I mean, does that code mean anything useful?
>>
>>    function() {
>>        {|a,b| a+b};
>>    }
>
> (You need a name for that function if it is a declaration, and from 
> the context you show, it is.)
>
> Does this perfectly valid JS mean anything useful?
>
>   function f() {
>     (function (a, b) { return a + b; });
>   }
>
> Nevertheless, it is legal. JS follows C (not Java) in allowing 
> seemingly useless expression-statements. This can be a source of bugs. 
> It is also required in some cases, namely when the function expression 
> (in parentheses) is the completion value of a Program. In such a case 
> that value could be the wanted result of eval or an eval-like host API.
>>
>> If not (as it seems to me), it means that a block lambda will not be 
>> used as a statement by itself. If it's the case, it should defined as 
>> an Expression only,
>
> Expression is already a kind of statement, via ExpressionStatement. 
> Furthermore, an ExpressionStatement *already* cannot start with a left 
> curly brace. Please read the grammar:
>
> 12.4 Expression Statement
>
> Syntax
>
> ExpressionStatement :
>     [lookahead ? {{, function}] Expression ;
>
> NOTE An ExpressionStatement cannot start with an opening curly brace 
> because that might make it ambiguous with a Block. Also, an 
> ExpressionStatement cannot start with the function keyword because 
> that might make it ambiguous with a FunctionDeclaration.
>
>> where there's no anonymous block to conflict the syntax.
>
> This is the conflict you're looking for.
>
>> That solution has been chosen for object notation in the past. That way,
>>
>>    function() {
>>        {
>>            (a, b)
>>            a.add(b)
>>        }
>>    }
>
> That is already valid ES1-6.
>
> Others have already replied, but the problem with redefining ( after { 
> without untenable newline sensitivity is it is a backward-incompatible 
> change.
>
> /be
>>
> François REMY <mailto:fremycompany_pub at yahoo.fr>
> January 12, 2012 2:23 PM
> Am I wrong if I say there not a bigger issue with block lambda than 
> with the current object notation on the matter?
>
> I mean, does that code mean anything useful?
>
>    function() {
>        {|a,b| a+b};
>    }
>
> If not (as it seems to me), it means that a block lambda will not be 
> used as a statement by itself. If it's the case, it should defined as 
> an Expression only, where there's no anonymous block to conflict the 
> syntax. That solution has been chosen for object notation in the past. 
> That way,
>
>    function() {
>        {
>            (a, b)
>            a.add(b)
>        }
>    }
>
> would still be an anonymous block where
>
>    function() {
>        asyncAction(..., { (a, b) a.add(b); } }
>    }
>
> would be a block lambda as an argument of an async function. No 
> semantic change for an identical syntax, in regards to strict ES5.
>
> The case where you would like to use a block lambda as a stament can 
> be resolved by adding parenthesis, like with the current object 
> notation. And since I still continue to hope we'll ditch the 
> unprefixed anonymous block in some future revision of ES, that very 
> small edge case could vanish at the same time.
>
> Does it seems possible/acceptable?
>
>
>
>
> -----Message d'origine----- From: Allen Wirfs-Brock
> Sent: Thursday, January 12, 2012 10:38 PM
> To: Thaddee Tyl
> Cc: es-discuss at mozilla.org
> Subject: Re: Block lambda is cool, its syntax isn't
>
>
> On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
>
>
> but it is ambiguous with  other currently valid statement blocks such as:
>
>   { (a, b) + b}
>
> or
>
>  { (a,b)
>     a+b
>  }
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> January 12, 2012 1:38 PM
>
> but it is ambiguous with other currently valid statement blocks such as:
>
> { (a, b) + b}
>
> or
>
> { (a,b)
> a+b
> }
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/00d81ff5/attachment-0001.html>
-------------- 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/20120112/00d81ff5/attachment-0003.jpg>
-------------- 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/20120112/00d81ff5/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1293 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120112/00d81ff5/attachment-0005.jpg>


More information about the es-discuss mailing list