ES6, ES7, and beyond(v8project.blogspot.com) |
ES6, ES7, and beyond(v8project.blogspot.com) |
FWIW, this:
For these reasons, the V8 team, along with TC39 committee members from Mozilla and Microsoft, strongly support denoting proper tail calls by special syntax.
All that said, I'm interested to see where the explorations go, and I'm looking forward to subsequent discussions.
I'm interested in getting everyone's point of view. We've been discussing pros and cons at https://github.com/tc39/proposal-ptc-syntax/issues and https://github.com/tc39/ecma262/issues/535 , and it'd be great to have your input, including the overturning-prior-consensus issues you raised in committee and anything else that comes to mind.
EDIT: How do you like the new wording "For these reasons, the V8 team strongly support denoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior, co-championed by committee members from Mozilla and Microsoft." ?
Your new wording seems totally fine -- sorry if I was pedantic, and I'm really not bent out of shape about your blog post. I just want to be sure that people don't get confused about where things stand. New features such as STC require time to bake (which is part of what the multi-stage lifecycle for proposals is all about) -- I only meant to clarify the state of the discussion.
Edit: Grrr, re-reading this it still feels like I'm speaking for Eric. He's his own guy, I should shut up about his position! All I mean to say is, I don't think anyone should be staking out strong positions at this point in syntax design. The design process is iterative and uncovers new constraints and effects, and we should all keep open minds and work collaboratively. I'm open to all possible outcomes: PTC, STC, no tail calls at all. Tricky space!
I'm from Lua originally and we've had tail calls forever... why would you point them out? It should be obvious:
return wat()
With implicit tail call elimination, those stack traces will change in non-trivial ways that could affect debugging processes or break existing tools.
I've also heard some concerns about implementation difficulties, but I know at least one major engine has implemented PTC as specified in ES2015 without issue. I think (and hope) these concerns are secondary to the discussion about stack traces and backwards compatibility.
tl;dr: as with almost every "why is it like that" question about JavaScript, the answer is "because backwards compatibility".
(I also started with Lua and have adjusted to JS over the years; they have more in common than many people realize!)
Finally left-pad module's functionality will be integrated into core! Souns awesome. /s
People writing polyfil's to add padStart to String.prototype used left-pad.
I was thinking these features are still 5+ years away unless you are prepared to actually ask your users to switch to Chrome.
For example, default arguments are purely syntactic sugar for `if (arg === undefined) { arg = x; }` in the first line of a function. Still, I'd much rather write ES6's declarative `function foo(arg=x) { }` syntax rather than imperatively implement it in ES5 each time I need it.
Of all the people on the web, or target audience of your website, or what market?
But yes, Node.js team, please don't inflict .mjs on us, or let your extreme NIH block the introduction of ES2015 modules.
Though there may need to be some considerations for `exports`/`module.exports` vs the `export` directive.
Seems like a good fit for EcmaScript. It might even help finally renaming the language, so that tech recruiters confuse it with something else ;)
At least if a recruiter starts asking you about your Eczema experience, you can more easily determine that the screening process has gone off the rails.
Although it's a cute suggestion.
Not to beat a dead horse, but I find it hilarious that this is a proposal. Someone on TC39 has a sense of humor.
Edit: Apparently this was proposed long before left-pad broke the internet.
https://github.com/tc39/proposal-string-pad-start-end/commit...
http://wiki.ecmascript.org/doku.php?do=revisions&id=strawman...
Well, just look at his profile picture:
Strong Seth Rogen vibes...
[Hey, I meant it as a complement!]
Of all the future developments in V8, this is what I'm looking forward to the most. It's the last key component tying most code to transpilers.
"The V8 team is already working to bring upcoming features such as async / await keywords, Object.prototype.values() / Object.prototype.entries(), String.prototype.padStart() / String.prototype.padEnd() and RegExp lookbehind to the runtime. "
I'm working on async/await in V8, together with Caitlin Potter. Browser support is in progress for Firefox and Safari as well. It didn't make the cut for ES2016, but it is at Stage 3 at TC39. I'm optimistic that it'll get into the main draft specification at the next TC39 meeting after we have a second spec-compliant browser implementation, which doesn't seem very far off.
It's even more of a step forward than Promises was.
Why do we need explicit tail calls with stack traces?
The problem with implicit tail call syntax is that suddenly stack traces will be elided from debugging info when you really just wanted a normal function call that happened to be in tail position. These are really hard-to-track-down bugs, since the stack frame that is elided is precisely the one that made the tail call.
It's a common thing in language standards to version by the year the standard was ratified, especially for ANSI languages such as C and C++, but there's a long history of it in language design including the ur-example off the top of my head of ALGOL68.
As for Windows 98. Would you seriously with a straight face want to admit to using a version of Windows that is old enough to vote? If anything, it's too bad they stopped that pattern with XP as it would have been a lot easier to shame people for still using Windows 2001 in 2015.
So it's not that standards become out of date, especially as in both Javascript and C++'s case, the standards are generally additive. They just add stuff so your old software should continue to work and will not become "out of date".
Anyway, that's the reasoning I've been given behind the change and it makes sense to me. Hopefully that answers the question for you as well.
C++03
C++11
C++14
C++17
Ubuntu?
16.04
13.10
9.04
If the end digit had matched, I suspect it would have worked out better, but with ES2015 and ES6 being equivalent, it's pretty confusing.
It's a bit of a funky one because it expands the scope of ES into what has traditionally been rendering engine territory (as in, an event loop). But I haven't seen resistance to it.
Of course, it will be nice to not need transpilers and I know a lot of people were hoping ES7 might be the end of it - but I don't see it happening anytime soon. Hopefully, though, more standards will be amenable to shims like this, so at least we can get them now while waiting on browser support. (That said, I hate web apps, this stuff drives me mad. I'll stick with GTK and WPF).
But I'm hearing that both the Babel and TypeScript implementations leave a lot to be desired with performance. Not so bad that it gave my use case a problem, but I use NodeJS, in part, for performance.
I'm also targeting browsers (and hybrid apps) with some code, and I've recently jumped from Babel/ES6 to TypeScript, so I can get the support via generators, but again I'm hearing of performance issues.
Getting first class optimized browser support is where I'll feel it's truly awesome.
https://www.npmjs.com/package/babel-plugin-transform-async-t...
So yes, this certainly feeds my point that standards years can be useful to point out the quirky failings of software by potentially adding to their shame. It's 2016, are you using an SQL-1986-compliant database?
Need is a strong word.
If I need that pattern, I'd rather write it declaratively than imperatively. :)