block-lambda revival

Tom Van Cutsem tomvc.be at gmail.com
Fri Jun 24 02:10:37 PDT 2011


Well, at least I'm consistent in producing this type of bug since I just
fixed another one: <
http://wiki.ecmascript.org/doku.php?id=harmony:proxy_defaulthandler&rev=1307082200&do=diff
>

Clearly, I have been spoiled, programming in languages with similar
higher-order functions but with proper block lambda's for too long! ;-)

2011/6/24 Mark S. Miller <erights at google.com>

>
>
> On Thu, Jun 23, 2011 at 10:00 PM, Brendan Eich <brendan at mozilla.com>wrote:
>
>> On Jun 23, 2011, at 9:49 PM, Mark S. Miller wrote:
>>
>> > Presently in JS, when seeing a "this", to understand what it means, the
>> eye needs to scan backwards for the closest enclosing occurrence of
>> "function" as a keyword. As this example shows, even this is accident prone.
>> If we introduce multiple special forms that can introduce a this-rebinding
>> boundary, where the new ones are easily missed, we make this burden worse.
>> Is "->" easily missed? (I would guess so.) And if it is, what are we getting
>> in exchange, and is it worth it?
>>
>> That's a good point if the special forms are not "just syntax" (including
>> some .bind or var self = this rewriting). Arrows at least do not add
>> semantically to the function-like menagerie, so the problem is not different
>> in kind from the one that bit the 'function'-based code you showed. But
>> block lambdas do not have the hazard at all.
>>
>> If you take your argument to the limit, it wants to kill 'this' (something
>> I believe you wouldn't mind ;-). This could be just another reason to prefer
>> block lambda revival to arrow function syntax.
>>
>> However, I recall from the last TC39 meeting that some folks on the
>> committee seemed outraged that block lambda revival (because of TCP
>> conformance -- no way around this) lexically binds 'this', always. I believe
>> the problem they had was that they believed shorter function syntax should
>> be neutral on 'this' binding, to make functions in all their current
>> use-cases more convenient.
>>
>> This is a difference in risk evaluation or tolerance, perhaps. We should
>> try to get to the bottom of it.
>>
>
> I missed the risk issue until today. I suspect others have as well.
>
> Until I started thinking about the implications of Tom's bug[1], I was also
> enthusiastic for shorter function syntax. Yes, I have always been even more
> enthusiastic about TCP-respecting lambdas, but put that aside for the
> moment. *Assuming* I couldn't have those or any other semantic improvement
> (const functions, etc), until today, my dominant reaction to JS functions
> has always been "But they're so darn verbose! Can I please have a shorter
> way to say these? Please?". Be careful what you wish for ;).
>
> The verbosity is a genuine cost. However, I didn't realize the hidden cost
> I was unknowingly willing to pay in exchange. If the tradeoff is against
> making it harder to spot errors when reading code, then I'd prefer to pay
> the current "function" verbosity cost. If you offered me "=>" in exchange
> for also accepting "->", I may have agreed yesterday. Today, not.
>
>
> [1] And that Tom made it. And that we all missed it for over 10 months.
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> 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/20110624/08f13912/attachment.html>


More information about the es-discuss mailing list