link Jan 30 Meeting Notes

John Neumann (JN), Allen Wirfs-Brock (AWB), Yehuda Katz (YK), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Rick Hudson (RH), Matt Sweeney (MS), Dmitry Soshnikov (DS), Sebastian Markbage (SM), Ben Newman (BN), Jeff Morrison (JM), Reid Burke (RB), Waldemar Horwat (WH), Doug Crockford (DC), Mark Miller (MM), Brian Terlson (BT), Luke Hoban (LH), Andreas Rossberg (ARB), Istvan Sebestyen (IS), Niko Matsakis (NM), Brendan Eich (BE), Rick Waldron (RW), Sam Tobin-Hochstadt (STH), Rafael Weinstein (RWS), Dmitry Lomov (DL), Niko Matsakis (NM), Simon Kaegi (SK), Dave Herman (DH)

link Parallel JavaScript

RH: API is stable

RH: Parallel array data type is no longer there. Instead as methods on arrays and typed objects.

NM: To be clear you can have an array with structs in it.

RH: The sweet spot is games and image processing.

RH: No current show stoppers on implementation. Some things to work out related to GC. The strategy going forward. Be complimentary to the typed object spec. Will track it and spec parts of it Typed Object spec. "Close follower". Will move in tandem.

LH: To move to phase 1 we need to see some examples.

YK: Agree, we need to see where we're at.

AWB: Agree, we should have presentations to move from phase 0 to phase 1.

RH: I have presented twice already...

YK: Moving to phase 1 should require a presentation.

YK: Concerned that we are exploding the API with mapPar, filterPar, fooPar etc.

YK: Prefer static functions

EA: Or a standard module import {map} from '@parallel'

YK: this in functions?

arr.map(obj.method, obj)

DH: The signature should just match the existing functions.

RH: Not less surprising. Just as surprising.

parallelModule.map(arr, func, ...)
// [T] -> .... -> [T]  // same return type

NM: What would you call from?

WH: It's too confusing to require completely different static function style for invoking parallel maps as compared to non-parallel maps. mapPar etc. method style is better than the proposed alternatives.

DH: It is always nicer to write a method call than a function call.

DH: Don't want a "bring me a rock" exercise.

EA: File issues on GitHub on the drafts (that are also hosted on GitHub).

MM: Worked well for Promises.

YK/MN to talk through the concern about a "ton of methods".

link Conclusion/resolution

• Move Parallel JavaScript to phase 1
• Talk offline about design issues further

link Structured Clone

DL: Is implemented in all browsers. Part of HTML spec. Hixie speced it. Hixie is happy with TC39 moving this to ES.

YK: Like to object to this motion. It is currently a giant set of scenario hacks.

DL: We want to add language objects that we want to transfer.

AWB: Cloning framework in ES.

DH: Is it possible to reform or do we have to start from scratch? Seems hard to reform. Too many issues.

MM: Fears that if we do not take it over and introduce something new. The old will continue to exist. We need a path to replace the existing system, including what PostMessage does.

DH: We need a roadmap. How do we handle transferables?

DH: Hixie (or Anne) added Map and Set to structured clone to HTML spec.

DL: We cannot add extensibility mechanisms if we do not own the spec.

YK: We should own the spec. Opposed to DOM specific extensibility methods. General extensibility mechanism are important.

BE: How would symbols work?

AWB: We have a symbol registry. As long as both side cooperate. Serialize to a registration key. The two sides need to agree.

MM: It is unobservable that the symbol is not the same across the two workers.

WH: What if you have the same symbol registered under two different strings?

MM: That can't be allowed.

BE: in the cross-machine limit, structured clone is serlialization/deserialization; start there, allow optimizations like Sun XDR, Van Jacobsen TCP/IP, Google protocolbuffers [discussion on optimization]

WH: What do we mean by optimization?

DH: [explains difference between opaque and structured clone, including implications on optimization]

WH: Are we going to settle on one of the two or do both?

DH: Both [more discussion on optimization]

BE: [explains history of prior work]

BE: Can't tell Hixie and Anne to stop adding to structured clone. Anne: Want to give them assurance that we will take over the effort.

WH: What's the consensus?

YK: We'll take it on. Move to stage 0.x

link defineGetter, defineSetter etc in Annex B?

BT: IE ships this.

MM: It would just be speced using defineProperty etc

AWB: Firefox does some strange things.

BE: please enumerate "strange things", file bugs

YK: It starts at level 1. Or 3? there are already implementations.

RW: What sites?

BT: Will attempt to furnish a list of sites...

link Conclusion/resolution:

• Makes sense to put in ES7 annex B
• Brian to write an initial speec draft

link Process document

Process doc is now public https://docs.google.com/a/chromium.org/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU

link Scheduling for next meeting

April 8-10 at Mozilla, San Francisco May 20-22 at Facebook, Menlo Park July 29-32 at Microsoft, Redmond Sept 23-25 at Bocoup, Boston Nov 18-20 at PayPal, San Jose

link Async/await

LH: https://github.com/lukehoban/ecmascript-asyncawait

LH, MM: await syntax is important because the precedence of await needs to be different than yield.

LH: async functions could be combined with function*; in such a thing we'd need both yield and await

MM, WH: What would the behavior of such a thing be?

LH: That's a seperate proposal - something we can discuss later.

BE: Syntax conflict with => functions (elided parameters). what does: async() // newline, no semi here => {...} ... mean? We can make it be an async arrow if we want, but second line looks like 0-param arrow function expression....

WH: async (a, b, c) => await d looks too much like a function call of a function named 'async'. Need to parse a long way before figuring out it's an async lambda. This wouldn't fall under the existing cover grammar.

LH: I'll look into that.

DH: Initially concerned about hard-coding the scheduler.

LH: Identical to Q.async. There is only one way to do this.

MM: September Promises consensus is superior to the Promises spec we have now. [Debate about whether we'll end up with two Promises APIs]

WH: Do the two APIs use the same scheduler (that would be hardcoded)?

DH: No.

LH: Can we move async/await to stage 1? General agreement

AWB: This means that we agree that this is something in a future version of ES

link Conclusion/Resolution

• Moved async/await to stage 1.
• Next step is to write real spec language

link Promises discussion

MM: Advocacy for .then()/.cast()

STH: Advocacy for .chain()

LH: Proposal of Promise.chain() compromise

YK: I would probably be ok with this

MM: I would probably be ok with this ... extensive discussion ...

MM: A resolve of a resolve does not create multiple levels of wrapping. Without chain this is not observable.

BE: .chain() requires over-wrapping/-unwrapping, without chain this is unobservable and therefore optimizable -- says to reject chain (surprised by own position changing)

YK: This persuades me that we shouldn't have .chain()

STH: I strongly disagree, but I'm not going to hold up ES6 over this

link Conclusion/Resolution

• Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
• Keep then, reject chain (NOT DEFER, reject!)
• Renaming .cast thus removes over-wrapping (always-wrap) deoptimization in old Promise.resolve

Some further discussion on keeping the spec inheritance/AOP-friendly by not using .then internally some times, short-cutting through internal methods or internal helpers other times YK, MM, AWB have details

link Jan 29 Meeting Notes

John Neumann (JN), Allen Wirfs-Brock (AWB), Yehuda Katz (YK), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Rick Hudson (RH), Matt Sweeney (MS), Dmitry Soshnikov (DS), Sebastian Markbage (SM), Ben Newman (BN), Jeff Morrison (JM), Reid Burke (RB), Waldemar Horwat (WH), Doug Crockford (DC), Mark Miller (MM), Brian Terlson (BT), Luke Hoban (LH), Andreas Rossberg (ARB), Istvan Sebestyen (IS), Niko Matsakis (NM), Brendan Eich (BE), Rick Waldron (RW), Sam Tobin-Hochstadt (STH), Rafael Weinstein (RWS), Dmitry Lomov (DL), Niko Matsakis (NM), Simon Kaegi (SK), Kevin Reid (KR), Dave Herman (DH)

link Function in Blocks in non strict mode.

(Ask Brian for slides)

BT: In ES6 draft in appendix B (since functions in block are not in ES5 but implemented)

BT: IE11 shipped with function in block in non strict mode.

BT: Hoists across let blocks

AWB: If you start using a let then you'll get an error. Since old code does not use let.

LH: If the code falls out of the known patterns you hit a rough edge and then it is better to get an error than undefined behavior.

WH: Concerned about expanding past the minimal crazy intersection semantics we agreed to in the past. The proposal expands the set of cases that produce surprise captures.

WH: [on whiteboard] This is not just about eliminating errors. It will silently change the meaning of working code:

function foo() { ... 1 ... }
function bar() {
  if (...) {
    function foo() { ... 2 ... }
  }
  foo(); // Thought it would refer to the outer scope foo. Surprise!
}

function foo() { ... 1 ... }
function bar() {
  if (...) {
    let foo =...;
    {
      function foo() { ... 2 ... }
    }
  }
  foo();
}

LH: Since 1.5% depend on the crazy behavior we have no real option.

WH: Let's limit the craziness to just the cases in the minimal intersection semantics.

BT: Allow hoisting past a let.

ARB: What was the motivation for this special case, i.e., why not drop all hoists that would normally be an error?

LH: Creates 2 bindings. The FunctionDeclaration itself mutates both the var binding and the let binding.

(function() {
  {
    let foo;
    {
      function f() {}  // Why no error?
    }
    console.log(foo);  // undefined
  }
  console.log(foo); // funtion foo() {}
})();

DH: If you inject a let and it shadows a var it should be a static error.

LH: In strict mode it is legal so it cannot be an error in non strict.

DH: It is consistent with a var in a block.

ARB: What happens if you have two functions

LH: You conceptually get two var bindings.

WH: That's not part of the intersection semantics. Shouldn't get any if you have two foo's in inner blocks.

YK: Writing new ES6 code in non strict should still work.

WH: It will silently do different and surprising things, as per examples above.

DH: If there is any intervening let binding do not hoist past the let.

LH: If introducing would introduce a static error. Do not introduce the var binding. [Discussion on the behavior of the new var bindings, along with whether assignment to foo updates one or both.]

WH: When are the crazy introduced var bindings initialized? At entry to outer function bar (just like ES5 inner functions in the top-level of an outer function), or at the time the inner function function foo definition is executed? Various: Set to undefined on entry to outer function. Set when inner function definition foo is executed. Various: Executing function definition updates both the let and the var bindings. Assignment updates only the let binding.

WH: [points out (and likes) warning on cases "for which the above steps are performed" in Annex B of the current draft] [Long discussion about warnings, SHOULD, and their audience]

LH: A SHOULD warning seems a reasonable addition to the proposal here.

link Conclusion/resolution

• 2 bindings.
• Hoist a var binding for the FunctionDeclaration, unless it would introduce a static error (ie. hoisting past a let will not cause an error but also not create the var binding).
• Also create a let binding as per pure (strict mode) ES6 semantics. (Change from IE11 semantics). Within the scope of the let binding, assignment will only touch the let binding (ie. normal semantics).
• The var binding is only initialized at dynamic evaluation of function declaration.
• A SHOULD warning if there is a reference to any such var binding of a function

link Object.observe Status Report

RWS: Suggest moving OO to the second stage. :: Approved

RWS: Wants to move OO to the third stage, which requires a spec text review.

YK: Has reviewed it already.

AWB: Might have time to review.

RWS: The plan is to ship OO in Chrome sometime around April.

AWB: Should not be a problem to advance without scrutizing the proposal. Willing to rubber stamp at this point. Since we are in a state where we are. (?)

YK: Once we are at stage 3 we are committed to not revisit.

RWS/YK to talk about task scheduling.

link Conclusion/resolution

???

link Post ES6 process

AWB: First step is to post the process somewhere public

AWB: Second, need a place to track the progress

AWB: Thinking we should do this on GitHub. Project TC39/meta. Master table. Or maybe 2 tables?

WH: Are we abandoning the wiki? Various: yes

WH: How do I view HTML instead of the HTML source on GitHub?

EA: We should also move the meeting notes from rwaldron/* to TC39/*

YK: We should use the GitHub API to extract the comments for keeping the paper-trail.

RWS: Agenda changes since last time 1. Add a designated reviewer. 2. At step 3 and 4 there is a requirement to get an approval from the spec editor.

RWS: Also managing spec in flight

YK: I'm going to work in that.

link Do Expression

(Ask for slides from ARB)

MM: An engine can statically detect an IIFE and treat it as a do expression.

DS: Important to scope var declarations to the enclosing function rather than the do block because that's what happens in a do-while loop, and it's hard to tell if you're looking at a do block or a do-while loop.

do {
  ...
}
 
while(true);

WH, DH: Expression statements cannot start with do to avoid syntactic conflicts.

BE: Just like function for FunctionExression which cannot start ExpressionStatement.

DH: Just use a parentheses if you really need to start ExpressionStatement with do.

AWB: What step is this in the new process? Step 0?

ARB: Can write spec

DH: Primary reviewer.

link Conclusion/resolution

• do-expressions as generailsation of block statements
• Progresses do-expressions to the next state in the new process.

link Security Review for Loaders/Realms

MM: We have considered a security review for Loaders & Realms

YK: Talked about this earlier, seemed positive

STH: Concerned about definition/scope KR Gave vague definition

MM: We'd like to do the same things we did in ES5 KR Considering porting SES to ES6. DH/ STH: this is an excellent goal

MM: What's the implementation status of Loaders/Realms

DH: Unpolyfillable, YK + DH tried some things w/ iframes, didn't work

DH: That's part of why we think it's a fundamental new primitive

link Conclusion/Resolution

• MM et al to port SES to ES6, contact module champions w/ results

link Typed Objects

Dmitry Lomov + Niko Matsakis

NM: Not objects

WH: Likes that === compares identities, but would prefer that == compare values.

NM: THat would be dangerous since structs are mutable.

WH: In that case, how do you compare values? That's a really common thing that users will want to be able to do.

ARB: Accessing a sub struct of a struct does not allocate any object.

NM: You can stack allocate

Line = new StructType({from: Point, ...})
line = Line(...)
while ( ... ) {
  foo(line.from)
}

DH: If line.from heap allocates it would be suprising.

WH: How does stack allocation work if the reference to the allocated object escapes the scope?

WH: Important to be able to mark StructTypes to always generate opaque fat pointers even if they don't have any 'any' field.

WH: This helps with optimization. Knowing that all instances of a StructType are opaque lets NaN-boxing implementations optimize out protection against NaN-injection on reads.

link Value Objects

http://www.slideshare.net/BrendanEich/value-objects2