Block lambda is cool, its syntax isn't

Rick Waldron waldron.rick at gmail.com
Sat Jan 21 15:09:53 PST 2012


>From a web development perspective, the small cost of a string literal "use
fn"; in trade for the reduced bytes of "fn" would be well received.

I recently delivered a fairly large scale mobile web application, to a
Bocoup client, that had 340 occurrences of "function" (that includes all
library and vendor code). That's 2720 bytes that can't be "minified" (but
thankfully will be gzipped). That would be only 680 with "fn" - more then
2kb difference (this stuff adds up).



On Sat, Jan 21, 2012 at 4:39 PM, Brendan Eich <brendan at mozilla.org> wrote:

>  François REMY <mailto:fremycompany_pub@**yahoo.fr<fremycompany_pub at yahoo.fr>
>> >
>> January 21, 2012 1:00 PM
>>
>>  -----Message d'origine----- From: Brendan Eich
>>> > François REMY <mailto:fremycompany_pub@**yahoo.fr<fremycompany_pub at yahoo.fr>
>>> >
>>> > January 21, 2012 1:34 AM
>>> > About the 'fn' proposal, I'm happy with it. Asking a 'use' statement >
>>> just for that feature may prove a little excessive but if it can be >
>>> merged with other can-be-breaking syntax reforms ('use es6')
>>>
>>> Please read the notes from the tc39 meeting, and the recent threads. We
>>> are not requiring version opt-in. New syntax is its own opt-in.
>>>
>>> The problem here is that 'fn' is not "new syntax" without complex
>>> parsing hacks. It's an unreserved identifier in ES1-5.
>>>
>>
>> If it's the case, we should avoid that. Avoiding 'use' for the whole
>> syntax and requiring it just for 'fn' is weird.
>>
>
> "Weird" doesn't quite dismiss the idea, since JS has 'function' and a
> shorthand for it -- along with a crucial new production adding an
> expression-bodied alternative short-function-expression -- is something
> users keep requesting. If the goal is to shorten 'function' yet keep a
> mnemonic shorter prefix, nothing grawlix will do. Why not 'fn'?
>
>
>  But I understand we can't use 'fn' per se since it breaks compat. We
>> should try to find something else (it's possible, at least).
>>
>
> Some here are positive on 'fn'. We have been searching for usable shorter
> syntax for a while. We should not dismiss 'fn' so quickly.
>
>
>>  > why not. But, seriously, what really makes it impossible to use # or @?
>>>
>>> We've been over this already. # is for freezing, @ is for private names.
>>> The Matlab precedent of @ for function is quite weak (thanks for pointing
>>> it out).
>>>
>>
>> Yes, but you didn't respond about where @ is used in private name, and
>> why it makes the @() syntax ambiguous with that use.
>>
>
> You have to follow the strawmen that haven't made it, in particular
>
> http://wiki.ecmascript.org/**doku.php?id=strawman:instance_**variables<http://wiki.ecmascript.org/doku.php?id=strawman:instance_variables>
>
> and
>
> http://wiki.ecmascript.org/**doku.php?id=strawman:classes_**
> with_trait_composition&rev=**1305852025#private_state<http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition&rev=1305852025#private_state>
>
> and es-discuss threads about foo at bar vs. foo. at bar, just @bar for
> this-relative addressing, etc.
>
>
>  Since the @ is never used in the private name proposal, I can't check
>> that on my own. My guess is that they don't collide.
>>
>
> They collide conceptually by overloading @ for two quite different things.
>
> If we want shorter *named* function expression syntax, then they collide
> syntactically with a fatal ambiguity absent more restricted productions:
>
>  @foo(bar)
>  { expr; }
>
> Is this an @-function-expression or a call to private this-relative foo
> passing bar?
>
>
>> Anyway, there are still other chars left, we should check if they are
>> easy to type on various keyboards (on my keyboard they are): ['6', '~',
>> 'µ', '£'].
>>
>
> Please re-read the recent messages on this thread: no non-ASCII. Also, ~
> is in JS already!
>
> /be
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120121/79a98ed3/attachment.html>


More information about the es-discuss mailing list