4 ms·

This presentation focused on work that's more recent. Improving the scoping story with let/const is one of the things that TC39 agreed on relatively early, tho

This presentation focused on work that's more recent. Improving the scoping story with let/const is one of the things that TC39 agreed on relatively early, though: http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:const http://wiki.ecmascript.org/doku.php?id=harmony:const http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_... Some of the new-function/lambda-syntax proposals even support Tennent's Correspondence Principle to some degree.

BrendanEich 14y ago
We gave up on TCP for => function syntax. I think Java reached the same conclusion. It's really hard to retrofit TCP onto a C-like language with statements as well as expressions. At best you please only some programmers and confuse others, at a fairly high implementation cost (e.g., return from within a lambda called after its containing function deactivated). See https://mail.mozilla.org/pipermail/es-discuss/2012-March/021872.html https://mail.mozilla.org/pipermail/es-discuss/2012-March/021... and especially https://mail.mozilla.org/pipermail/es-discuss/2012-March/021879.html https://mail.mozilla.org/pipermail/es-discuss/2012-March/021....
- surrealize 14y ago
  Thanks, it's nice to hear it from the horse's mouth. Does it make sense to think about TCP as being a matter of degree? Would it be correct to say that the number of constructs that would break TCP is fewer with let, const, and => than with earlier versions of ES? I think a "partial TCP" would matter for manual refactoring, if not for (e.g.) a future macro system. On the other hand, perhaps it's more confusing to mention it if it's not total.
  - BrendanEich 14y ago
    Saw dherman's comment just now, he and you are right that there is a spectrum of TCP, and if you use a subset of JS to write expression-bodied => functions, you get the refactoring property that people associate with TCP.
- dherman 14y ago
  Though the expression version of => comes pretty close to TCP. Dave

BrendanEich 14y ago

We gave up on TCP for => function syntax. I think Java reached the same conclusion. It's really hard to retrofit TCP onto a C-like language with statements as well as expressions. At best you please only some programmers and confuse others, at a fairly high implementation cost (e.g., return from within a lambda called after its containing function deactivated). See https://mail.mozilla.org/pipermail/es-discuss/2012-March/021872.html https://mail.mozilla.org/pipermail/es-discuss/2012-March/021... and especially https://mail.mozilla.org/pipermail/es-discuss/2012-March/021879.html https://mail.mozilla.org/pipermail/es-discuss/2012-March/021....

surrealize 14y ago
Thanks, it's nice to hear it from the horse's mouth. Does it make sense to think about TCP as being a matter of degree? Would it be correct to say that the number of constructs that would break TCP is fewer with let, const, and => than with earlier versions of ES? I think a "partial TCP" would matter for manual refactoring, if not for (e.g.) a future macro system. On the other hand, perhaps it's more confusing to mention it if it's not total.
- BrendanEich 14y ago
  Saw dherman's comment just now, he and you are right that there is a spectrum of TCP, and if you use a subset of JS to write expression-bodied => functions, you get the refactoring property that people associate with TCP.
dherman 14y ago
Though the expression version of => comes pretty close to TCP. Dave