John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark S. Miller (MM), Tom Van-Cutsem (TVC), István Sebestyén (IS)
MM: ...Continuing from yesterday
AR: https://github.com/slightlyoff/Futures/blob/master/Promise.idl (https://web.archive.org/web/20131001060533/https://github.com/slightlyoff/Promises/blob/master/Promise.idl)
STH: Don't like resolve but not willing to die on this hill.
AR: DOM has a bunch of ad hoc APIs to do promise like things.
YK: Mozilla is also actively working on APIs using promises.
AR: A lot of methods today return void so we can change these to return a promise. This is forward compatible.
AR: then does recursive unwrapping...
LH: The important part is not the features but the process.
AWB: Can things be decoupled?
LH: These kind of structural questions are the important part
MM: Suggests "concurrency" to be the main theme.
AWB: Thought about the event loop. All we need is a processing queue... put things in the front and the back.
DH: Only need to add to the back.
AWB: OK.
STH: The callback is called at some later point.
AR: Don't think we need to specify the order.
STH: If we are going to specify promises etc we need to be able to specify things in detail. We can be loose in ES6 and then come back in ES7 and provide a more tight spec.
DH: We could specify the pending events as a set or something. Not sure if there is a consensus that we want a fast small ES7. Not opposed to a modularized approach.
AR: Are there any browsers that are not shipping stable ES6 features today.
YK: Yes. V8.
AWB: Where we have problem today is that there is a lot of interdependency.
MM: These ("concurrency") are coupled together to the event loop
AWB: We can do it as a separate non 262 spec
DH: Opposed to a separate spec. Introduces versioning confusion.
AWB: Roll up
DH: Think of all the extra overhead.
STH: Big difference with 402 since it was run by different people.
LH: Lack of confidence in new features has been an issue for implementers. Good exceptions were Object.observe and Proxies where the wiki contained a mostly complete spec.
AWB: We need to have wiki proposals be deltas to the spec.
TVC: We could have "stable" wiki pages. These would have complete spec deltas.
DH: Very concerned about over modularizing.
AWB: We need to find a way to work faster and be less monolithic.
DH: Agree. ES6 process has blocked implementation work.
LH: We are not committed to our designs.
STH: We are not resolving issues until we start to spec. We are not getting feedback until engines starts to implement.
EA: The problem is that we didn't start to spec things until very late. We had agreements on features long before there was any spec drafts for them.
YK: More from our champions before we get to concensus.
ARB: Lots of the proposals were very vague.
AWB: The more complete spec you bring to tc39 the better chance you have to reach consensus.
ARB: Lack of early spec leads to lack of early implementations...
AWB: ...which leads to lack of feedback.
LH: Not more work, just doing the work earlier before things pile up too much.
DH: Need to look at the dependency graph. Hold of the work of later feature.
ARB: We need to higher bar before we accept proposals.
MM: What we agreed to 2 years ago was that the features are the one we want to spend work on speccing.
LH: Less features to bite of.
DH: A lot of us have a hard time not getting too engage in too many features.
YK: if we focused more effort on managing the overall complexity instead of getting stuck on a lot of technical discussions (and nit picking).
DH: Object.observe and Proxy moved fast but are fairly isolated features
TVC: Didn't involve syntax.
AWB: With ES6 we had a long backlog.
DH: A language will have smaller and smaller complexity budgets as it grows.
AR: ES future needs events
DH: Since this is Mark's wishlist people will throw in their pet features.
MM: This is the direction I am going to work.
LH: There is a page on the wiki outlining the goals.
LH: Looking for 2 things: Something that would allow earlier implementations. Have not brought proposals (over the last 2 years) because we have been blocked by ES6.
LH: When is the appropriate time to bring new proposals to TC39?
AWB: We are free to do what we want. We can issue 6.1, 6.2 etc or technical reports which would serve as a recommendation.
DH: We cannot exclusively work on ES6.
YK: Time at f2f is the most important. Champions can go off and do what they want.
DH: Suggests adding non ES6 items to the agenda. We will prioritize the non ES6 stuff we can get to given our limited time.
YK: We should reinstate the rule that agenda items needs links to wiki pages.
YK: Spec language is good but examples at the top are a must.
ARB: Add step after proposal. For example "stable" or "spec" which a proposal gets promoted to once there is a spec draft, good enough to start implementing.
DH: Strawman: Anything goes.
YK: Proposals used to mean approved.
DH: 3 sections: strawman, proposal, spec/candidate. Keep strawman. Work on improving as a proposal, and when mature enough promoted to next level.