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

link Jan 28 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), Simon Kaegi (SK), Dave Herman (DH)

IS: Talk about the royalty free task group

JN: Approved, 9 in favor. 0 opposed. 0 abstains. We are now operating as a Royalty Free Task Group

JN: Netflix and Apple haven't returned the paper work.

IS: Neither from Brown University. (and a bunch of other universities that are not active any more)

link Agenda

JN: Agenda approved https://github.com/tc39/agendas/blob/master/2014/01.md

JN: Minutes from Nov meetings also approved. (https://github.com/rwaldron/tc39-notes/tree/master/es6/2013-11)

link Spec Status update

AWB: Latest draft (Rev22) is the "almost feature complete" version. (Discussion about process troubles). Spec now uses a master document and is split into multiple files.

AWB: Still some work to do on Direct Proxies. Update spec for C-style for-let. Loaders and Realms are integrated into the spec draft. Lots of review needed.

EA: Standard modules were deferred at last F2F

LH: We agreed on globally reachable names for all pre-modules APIs last September. New names for module loaders APIs need similar design.

AWB: Loader and Realm are speced as %Loader% and %Realm% since we haven't talked about their public names.

DH: Where does Reflect go?

AWB: Use a global.

DH: Realm can go in Reflect since it is a very reflective thing.

DH: We can probably defer System too.

YK: We need an entry point and a global named System seems to be good.

DH: Loader can go in Reflect too.

AWB: Need to update the spec draft to match the scoping rules we agreed to before.

link Resolution

link Aside on detecting Module vs. Script (see http://esdiscuss.org/topic/detecting-js-language-mode-for-tools)

Debate about whether it's required (partial agreement that it is since they are clearly distinct)

WH: Even though they're distinct, doesn't mean that they must be ambiguous with each other at the source text level. We could easily say that a module has to start with some syntax that designates it as a module.

AWB: Spec doesn't necessarily need to address this (why?) but we should consider setting the direction here. If we're fine with the community coming up with something here we can lean on that too.

LH: This process has to happen, there will be lots of solutions, we might not pick the best one.

Potential solutions:

• YK: Bower uses metadata for packages that say they're ES6 module
• DH: Possibly do nothing, we live in this world already today
• DH: Come up with some kind of syntactical distinction
  • DH: This sucks, modules should not require additional boilerplate to be valueable
• Possibly use file extensions...

link Conclusion/resolution:

• DH to do the work?

link Task and Tasks Queues

Postponed until tomorrow when Raf is here.

link Process for ratifying ES6?

LH: We have now effectively met the "feature complete draft" requirement we were targetting. Are there any process requirements this group is placing on progressing the spec to ratifica

BE: Have nothing, same as ES5. (Discussion about whether we can be strict)

LH: For example, do we have "multiple compatibile implementations" requirements? Or "test262 coverage" requirements? Our ES7 process proposal has these, but do we want/need some limitied version of this for ES6?

AWB: We just need to ship it and get to the stricter process for ES7.

MM: We can always postpone features to ES7 if they seem to be problematic.

BE: For example, there is unlikely to be an implementation of proper tail calls before we send ES6 to the GA, then to ISO. I don't think we should defer them on that basis, but it's a fact. We should not slip ES6's schedule.

LH: If by the time we ratify ES7 and there are still ES6 features that have not yet been implemented by anyone, we should re-evaluate if we can remove them.

link Resolution

The commitee is putting no blocking requirements of implementations or tests on standardization of ES6.

link Concise methods and Enumerability

YK: People have object literals today and use these objects with for-in loops to find the properties and if they change to non enumerable consise methods things will break.

AWB: Concise methods were initially non-enumerable. This was to match the built-in classes, like Date, Array etc. One possibility is to make methods in classes non enumerable but concise methods in object literals enumerable.

RW: The same issue happens when people use object literals as the prototype.

AWB: Should Map and Set methods be enumerable then?

RW: The spec should be consistent with itself.

WH: User-defined classes should be consistent with built-in classes. Classes are new in ES6. The question is whether it's the class that turns off enumerability or the concise method that turns off enumerability.

WH: My preference is for the consise method syntax to turn off enumerability. In the rare cases that you want an enumerable method in a prototype, you can define it the longer way.

YK: Refactoring should be simple and not have side effects like these.

RW: hasOwnProperty solves the problem of filtering out class methods inherited from the prototype, so we don't need to make them non-enumerable.

BE: people don't use hasOwnProperty

YK: enumerability is broken, we should not discuss the Platonic ideal form of enumerability

BE: According to Neo-Platonic Mystics, the material world was created by the evil Demiurge, not by Sophia (wisdom). Enumerability and 'for-in' are from the Demiurge.

BE: Enumerating options: * Concise methods and class methods are enumerable * Current es6 draft state * Split the difference, concise methods enumerable, class methods non-enumerable. * can't refactor between es5 object literal and es6 class/concise methods depending on which is non-enumerable * Make both non-enumerable (Waldemar supports) * same refactoring hazard, possibly not desirable * Some tilde-based or better syntax to allow developers to pick, but go with option 1

YK: Hope that we can use annotations in ES.Future that can control this kind of details.

BE: Agree, so fourth option above.

YK/LH: High bar to make a change, does this meet the bar?

link Conclusion/Resolution

• Status quo. Keep concise methods enumerable.

link More on toMethod

AWB: Function.prototype.toMethod(superBinding, methodName = undefined) Footgun to put this on Function.prototype.

MM: potential suprise: in the absence of toMethod, super's interpretation can't change, but now people have to account for possibility of shifting interpretation, which requires them to know about toMethod (not sure if I'm getting this right- BN)

AWB: The footgun is that we do not propagate any properties.

AWB: Suggest moving toMethod to Reflect

DH: Needs to be renamed then.

?: Suggests renaming to bindSuper.

WH: We've discussed all of this before and reached consensus. bindSuper is a bad name because it intentionally doesn't commute with bind.

WH: [reviews consensus from past meeting]

AWB: expect people to define Object.defineMethod in terms of toMethod, with copying of properties

DS: do we also need toStaticMethod?

AWB: no, you can just use toMethod with the constructor function as the superBinding / home object

BN: are static/class methods inherited?

AWB: yes

AWB: should we copy .name and/or .length to the new function object?

MM: use bind as a precedent to decide what to copy (mixed messages though: bind does copy .length, minus the number of curried arguments, and (in SpiderMonkey at least) copies the .name, though V8 gives the bound function an empty string .name)

AWB: What should happen if toMethod is called on a non ECMAScipt function object (built-in)

MM: How about just returning a clone of the function. You could even even delegate in a similar way as bind.

AWB: Only allow toMethod on unbound methods?

MM: to preserve possibility of transparent monkey-patching, either make toMethod return something that can't be toMethod-ed again, or allow built-in (non-ECMAScript Function Object) functions to be cloned, which requires an additional path in the internal CloneMethod operation (because it currently asserts that the clonee is an ESFO)

link Conclusion/Resolution

• Allen to take it back to the lab. To get it to work with bound functions and built-ins.
  • Make it match old concensus func.bind().toMethod(...) should throw
  • Does not work on proxies

link Clz (count leading zeros)

WH: Don't like deliberately introducing anachronisms a la 1900-origin getYear into the language. Would prefer to have it be origin-0 instead of origin-32 (i.e. return 0 instead of 32 when called on 0) to avoid hardwiring a machine word size. However, understand that we want this to compile to an efficient low-level primitive, so it would still have the toUInt32 as part of its semantics. In that case we should call it clz32 instead of clz so that later we can do clz64 (that would call a future toUInt64) or other variants.

BE: Want it to map to one single machine instruction

BE: Mislocated, should be on Math

BE: (missed the third point)

BE: CLZ - for cases when you're doing DSP-level hacking, and want to count the number of populated bits. Also important for native-to-js compilers, there is an intrinsic for this in GCC and Clang. BE: Math.clz32 wins.

link Conclusion/Resolution

• Rename to Math.clz32 (rename and move from Number.prototype)

link Array.from

AWB: What should happen with Array.from(undefined)?

EA: Array.from is a likely replacement for Array.prototype.slice.call and the array generics do ToObject.

AWB: Array with holes would lead to to a dense array.

YK: Want to keep the holes.

BE: "Holes are from the devil"

link Conclusion/Resolution

Keep as spec'ed. * Array.from will throw on undefined and null * Array.from will return [] for 3 * Array.from([0, , 2]) => [0, undefined, 2]

link Test 262

BT: Up on GitHub. https://github.com/tc39/test262. Conversion from Mercurial done by Brandon Benvie.

BT: AttendedTest the web forward. Got a lot of PR (22).

BT: Pending contributor guidelines.

BT: Going to work on style guidelines since the PRs are inconsistent.

IS: Getting CLA working is highest prioroty.

BT: Do we need any test coverage before approving ES6?

BT: For ES7 we agreed that we need tests before final spec.

BT: Instead of using numbered section plan to use the HTML anchor names from the HTML version of the spec.

link Yield and its precendence

Code Samples: https://gist.github.com/lukehoban/8678463

LH: Presents code samples. All but "yield 1+2" seem strange. Any time you have a generator that pumps values in you want good expression semantics.

WH: Points to yield 1+2 alternatives in LH's code samples; one makes it mean (yield 1)+2, the other makes it mean yield(1+2). Strongly prefers the latter.

BE: Have to make a choice that yield should be high precedence or low precedence. yield x + y must be yield(x + y) without parens, the rest follows by the grammar.

LH: concede

:: conversation about whether implementing iterators is more common or taskjs-like scenarios are more common ::

BN: Status quo causes more errors but errors encourage parenthesization, and enables yield 1 + 2 to yield the value 3

LH: For the async use case, important to have high precendence, but willing to concede that yield should remain low precenedence due to iterators use cases. Async use cases could have new "await" syntax with high precendence.

YK: task.js requires (yield a) + (yield b) paren style

BE: revenge of Lisp, you get used to it

link Conclusion/Resolution

• Status Quo

link Newborn generator behavior

(Ben)

See issue here: https://github.com/tc39/agendas/pull/25

DH: Intention was for generators to be composable.

BN: Proposal: generator with yield* doesn't throw when receiving a value

DH: Breaks correspondance between yield* and for-of desugaring. Also... wrappers are not equivalent unless both wrapper and wrapped are newborn.

BN: Can be fixed... but is hairy. Presents updated wrapper code... Proposal is that we remove the type error for passing in a value to an unborn generator. Then, if the first yield we encounter is a yield *, pass in the value that was passed to the unborn generator. :: Concerns with proposal (please fill?) ::

DH: Possibly other alternatives to fix this?

WH: There are two problems here:

1. A function* can't capture the first value passed to the 'next' that invoked it. Instead, it currently requires it to be undefined.
2. No way to pass an initial 'next' value to yield *. This means that manually doing the first yield followed by a yield * wouldn't help because the problem would then reappear on the second yield.

WH: The proposal is proposing a hidden channel (a la Perl's $_) that ties 1 to 2 here. Would prefer mechanisms to do those separately and more explicitly.

BN: yield syntax that says delegate but don't care about value?

DH: Let's think about it more...

DH: Went through the mental excercise to do an implicit yield upon calling the generator. Leads to a lot of other issues.

function* first() {
  return yield* push(first, delegate);
}

link Concensus/Resolution

• BN: Have to go back and think more about this. Maybe a helper function can be created.

link ECMA-404 and IETF interactions

AWB: IETF is not comfortable referencing ECMA.

IS: IETF includes ECMA-404 as an informative reference (?)

AWB: Proposed doing a second edition if IETF wanted to work with ECMA. :: Discussion about IETF participation, general dissatisfaction with the process and end result :: See http://www.ietf.org/mail-archive/web/json/current/threads.html#02131 and look for "R S" (Rob Sayre) fighting the good fight