On Thu, Jun 23, 2011 at 10:00 PM, Brendan Eich <bren...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
