Block lambda is cool, its syntax isn't

Brendan Eich brendan at mozilla.com
Thu Jan 19 15:05:36 PST 2012


Now you are forgetting the argument that TCP-conforming block-lambdas 
*should* look quite different from ...(params) {body} functions. This 
implies that shorter function syntax ought to follow the (params) {body} 
plan.

/be

> Herby Vojčík <mailto:herby at mailbox.sk>
> January 19, 2012 11:40 AM
> Brendan Eich wrote:
>> Axel Rauschmayer <mailto:axel at rauschma.de>
>> January 19, 2012 9:31 AM
>>
>> Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
>> you want anything else, you can use a traditional function. Then the
>> above syntax as the only function shorthand would be OK.
>>
>>
>> First, #(params) { body } was proposed by Arv and Alex:
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
>>
>> Arv and Alex feel strongly that the shorter function syntax (anything
>> shortening 'function' syntax) must not freeze by default.
>
> Well, if #(x, y) {x+y} is not good because of # is used for freezing 
> and freezing is not good (it is not, metadata is good argument for 
> that), and if something-like-lambda-block is ok, some variation of 
> lambda-block could be the shorter replacement for functions. These 
> come to mind:
>
>   {*a, b* a+b}
>   {/a, b/ a+b}
>   {^a, b^ a+b}
>   {%a, b% a+b}
>
> and there is still more infix operators...
>
> maybe even {`a, b` a+b} if it does not create conflict in this context.
>
>> /be
>
> Herby
>
> Brendan Eich <mailto:brendan at mozilla.com>
> January 19, 2012 11:27 AM
> Axel Rauschmayer <mailto:axel at rauschma.de>
> January 19, 2012 9:31 AM
>
> Rationale: wouldn’t freezing by default be OK for 98% of the cases? If 
> you want anything else, you can use a traditional function. Then the 
> above syntax as the only function shorthand would be OK.
>
>
> First, #(params) { body } was proposed by Arv and Alex:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
>
> Arv and Alex feel strongly that the shorter function syntax (anything 
> shortening 'function' syntax) must not freeze by default.
>
> There was lack of clarity about whether completion value as implicit 
> return value was part of the proposal. If so, controvery, since there 
> is a completion value leak hazard. TC39 seems to agree the solution 
> there is something with different look & feel, such as block-lambdas.
>
> But, making a one-char grawlix shorthand for 'function' while still 
> requiring 'return' is not considered enough of a shorthand. A possible 
> cure here is to support an alternative body syntax: #(params) expr. 
> However, this inverts precedence if done naively. It also runs into 
> trouble trying to prefer an object literal over a block statement. 
> I've worked on both of these in the context of
>
> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
>
> This superseded shorter_function_syntax, but ran into grammatical 
> issues that have vexed it.
>
> But notice that throughout this, no one advancing a proposal advocated 
> freezing by default. JS developers use function objects as mutable 
> objects. Not just to set .prototype, also to decorate with ad-hoc and 
> meta-data properties. Freezing is not wanted by default.
>
> I agree that for block-lambdas it's easier to say "freeze by default". 
> For merely "shorter function syntax", no. Functions are mutable 
> objects by default in JS. This matters for minifiers, which may not be 
> able to see all the mutations but would love to use shorter syntax for 
> 'function' syntax, blindly.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Axel Rauschmayer <mailto:axel at rauschma.de>
> January 19, 2012 9:31 AM
>
> Rationale: wouldn’t freezing by default be OK for 98% of the cases? If 
> you want anything else, you can use a traditional function. Then the 
> above syntax as the only function shorthand would be OK.
>
> -- 
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>
>
> home: rauschma.de <http://rauschma.de>
> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
> blog: 2ality.com <http://2ality.com>
>
> Brendan Eich <mailto:brendan at mozilla.com>
> January 19, 2012 9:25 AM
>
> I'm not sure what you mean. I proposed this a while ago ("Harmony of 
> My Dreams") but we don't want frozen by design, and without the # the 
> result is ambiguous without restricted productions, and hazardous on 
> that account.
>
> The idea that any grawlixy preifx will do is false. Hash is wanted for 
> consistent freeze/seal prefixing. Arrow is better and putting it at 
> the front solves the grammar problems with arrow function syntax as 
> current drafted.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Axel Rauschmayer <mailto:axel at rauschma.de>
> January 19, 2012 12:06 AM
>
>
> Couldn’t one always freeze such a function shorthand and then get 
> syntax such as:
>
>      #(x, y) { x + y }
>
> -- 
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>
>
> home: rauschma.de <http://rauschma.de>
> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
> blog: 2ality.com <http://2ality.com>
>


More information about the es-discuss mailing list