Why no tail calls from generators?
Hi! I tried searching the archives and a bit around the Web, but couldn't find a place where this was written down; I may just need a pointer. What is the rationale for explicitly disallowing PTC in generators? (Or, in the case of proposals like STC, why not allow users to opt in to TCO in generator bodies?) Specifically, I'm referring to step 5 in IsInTailPosition that returns false ( http://www.ecma-international.org/ecma-262/6.0/index.html#sec-isintailposition) if the body is a generator body. Thanks! Joe P ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On Thu, Aug 27, 2015 at 2:58 PM, Alexander Jones a...@weej.com wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant whitespace. ``` -x**2 === -(x ** 2) -x ** 2 === (-x) ** 2 ``` One kind of cost that I haven't seen mentioned (and is relevant re:whitespace) is the impact on minifiers and other tools that use JS as output, which have to deal with operator precedence/whitespace rules in quite complicated ways. There's a nice recent piece about precedence bugs in a minifier: https://zyan.scripts.mit.edu/blog/backdooring-js/ Making the creation and maintenance of systems like minifiers harder is a real cost worth bearing in mind when updating already-subtle existing rules. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: testable specification
If you're curious about interpreters, I'd like to point out that we have one that we think is pretty decent: https://github.com/brownplt/LambdaS5 It now has reasonable, though incomplete, coverage of Test262: http://cs.brown.edu/~joe/public/results/summary.html Further, it implements much of ES5 in a clearly defined specification language: https://github.com/brownplt/LambdaS5/blob/master/envs/es5.env It's built for understanding, not for performance, which makes it a good fit for playing around with new features (we have our eye on proxies), and ironing out test suites. We think it's a great implementation to tinker with--do have a look, and see what in the approach might help with the ES6 specification effort. On Wed, Oct 26, 2011 at 3:08 PM, Michael Dyck jmd...@ibiblio.org wrote: According to http://wiki.ecmascript.org/doku.php?id=harmony:harmony goal #2 of Harmony is: Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. Is there much activity toward this goal? The current ES6 drafts are using mostly the same formalism as ES1 (although there was a marked de-spaghettification between ES3 and ES5). (I ask because, in my spare time, I'm developing a process that massages the ES spec into an executable/testable form. So I wonder if I'm duplicating existing work.) -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
