<div dir="ltr"><div># July 30 2014 Meeting Notes    </div><div><br></div><div><br></div><div>Brian Terlson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy Patino (CP), Sebastian Markbage (SM), Istvan Sebestyen (IS), Erik Arvidsson (EA), Brendan Eich (BE), Mark Miller (MM), Sam Tobin-Hochstadt (STH), Domenic Denicola (DD), Peter Jensen (PJ), John McCutchan (JMC), Paul Leathers (PL), Eric Toth (ET), Abhijith Chatra (AC), Jaswanth Sreeram (JS), Yehuda Katz (YK), Dave Herman (DH), Brendan Eich (BE), </div>

<div><br></div><div><br></div><div><br></div><div><br></div><div>## RFTG Admin: ES6 Opt-out period. </div><div><br></div><div>(Allen Wirfs-Brock)</div><div><br></div><div><a href="https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/ecma-262-6-optout1.pdf">https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/ecma-262-6-optout1.pdf</a></div>

<div><br></div><div>AWB: This is the opt-out period: Aug. 11, 2014 - Oct. 11, 2014</div><div><br></div><div>Final opt-out window: March 16, 2015 - May 18, 2015</div><div><br></div><div>Read the policy, speak with Istvan Sebestyen for further information. </div>

<div><br></div><div>The opt-out version of the spec is: ECMA-262 6th Edition, revision 26, document: tc39/2014/031</div><div><br></div><div><br></div><div><br></div><div>## 4.4 Instantiation Reform (Review @@create design rationale and possible alternatives)</div>

<div><br></div><div>(Mark Miller, Allen Wirfs-Brock, Dmitry Lomov, Tom Van Cutsem. Based on Claude Pache proposal )</div><div><br></div><div><a href="https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/instantiation-reform.pdf">https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/instantiation-reform.pdf</a></div>

<div><br></div><div>AWB: Currently: </div><div>    </div><div>```js</div><div>new Foo(arg)</div><div>```</div><div><br></div><div>1. `Foo[[Construct]](arg)` ::=</div><div>  1. `let obj = Foo[@@create]()`</div><div>  2. `foo.call(obj, arg)`</div>

<div>  </div><div>The actual constructor method typically does all of the initialization and setup on the instance object.</div><div><br></div><div>Issues: </div><div><br></div><div>(DOM centric)</div><div>1. If instances aren't sufficiently initialized by @@create, then instance objects could leak (e.g. via a nefarious decoupling between the @@create allocation process and the constructor-function initialization process)</div>

<div>2. @@create could be called directly</div><div><br></div><div><br></div><div>DH: Do we have concrete examples of this problem?</div><div><br></div><div>JM: Dealing with legacy code where you want to subclass from legacy constructors, need to set up state, `this` uninitialized</div>

<div><br></div><div>AWB: Gives `Date` example, where `[[DateValue]]` isn't setup until `super()`</div><div><br></div><div>DH: The initialization of the internal field cannot happen until the super constructor is called to create _that_ field.</div>

<div><br></div><div>YK: This is caused by the @@create not accepting the constructor arguments.</div><div><br></div><div>AWB: Yes. Propose: Remove @@create, replace it with @@new, which will make the arguments available to </div>

<div><br></div><div>YK: When you subclass, it's normal to call super and pass the arguments. </div><div><br></div><div>AWB: @@create is a property of the constructor, not the instance.</div><div>Creating a subclass, you may want to do something with the arguments before passing to `super`</div>

<div><br></div><div>JM: or adjust some state on the subclass instance before calling `super`</div><div><br></div><div>AWB: There is a complication that built-ins have: different behaviour when `new`'ed or `call`'ed</div>

<div>No internal distinguishing mechanism. No way to indicate that a constructor was called or newed.</div><div><br></div><div>YK: Don't think we need to be concerned with handling </div><div><br></div><div>AWB: A subclass will create a "call" up to the `super`</div>

<div><br></div><div>Explanation of current spec handling.</div><div><br></div><div>JM: Issues: were we called, or newed. One deals with intermediary state initialization.</div><div><br></div><div>AWB: The issue is coupling between state and the instance. </div>

<div>Do we agree that there's a problem?</div><div><br></div><div>(no one says no)</div><div><br></div><div>JM: There are scenarios where a subclass wants to initialize state before calling super()</div><div><br></div>

<div>YK: It seems like a feature, not a bug</div><div><br></div><div>WH: What are you calling the intermediary state</div><div><br></div><div>YK: The fact that you can observe the creation</div><div>There has to be brand check</div>

<div><br></div><div>DH: The simplest way of saying is that all need brand checks.</div><div><br></div><div>YK: Can do: `foo.call(any)` and there is obviously a check there.</div><div><br></div><div>AWB: Internal slots are initialized in an atomic unit, </div>

<div><br></div><div>YK: </div><div><br></div><div>DL: TypedArrays missing creation information</div><div><br></div><div>AWB: You can move all the logic [to @@create or @@new or something akin], but you've just created another constructor</div>

<div><br></div><div>WH: Why not do everything from @@create in the constructor</div><div><br></div><div>DL/AWB: Jason Orendorff's proposal.</div><div><br></div><div>DH: (not-quite-right summary of Jason's proposal)</div>

<div><br></div><div>AWB: One way: reify [[Construct]] to the user</div><div><br></div><div>DH: When `new Foo(args)`, calls `Foo[@@new](args)` ... ?</div><div><br></div><div>DL: Just pass the args to `@@create` and change `@@create` to `@@new`</div>

<div><br></div><div>NM: But then the subtype must have same signature</div><div><br></div><div>AWB: 2 viable options for ES6</div><div><br></div><div>- Live with what we have, @@create is grungy, but not unsafe</div><div>

- Alternative, originating with Claude Pache</div><div><br></div><div>Bring back to constructor with atomic invocation. I'm for this approach and it's reasonable for ES6</div><div><br></div><div>(Mark presenting...)</div>

<div><br></div><div>MM: </div><div><br></div><div>Goals</div><div><br></div><div>Subclass exotics</div><div>Avoid un (or partially) initialized exotics</div><div><br></div><div>ES5 compat (aside from "rcvr")</div>

<div>ES6 class compat (aside from @@create)</div><div>Reliable test for "am i called as a constructor?"</div><div>Support base-creates-proxy scenario</div><div><br></div><div><br></div><div>```js</div><div>class Derived extends Base {</div>

<div>  constructor() {</div><div>    // TDZ this, on "new Derived..." etc.</div><div>    super(...otherArgs); // this = what super returns</div><div>    // this is initialized.</div><div>  }    </div><div>}</div>

<div><br></div><div>// </div><div><br></div><div>function Base(...otherArgs) {</div><div>  // implicit this = Object.create(mostDerived.prototype, {});</div><div>}</div><div>```</div><div><br></div><div><br></div><div>AWB: The `super()` call is calling the super class constructor as a _constructor_ when `new Derived()`—that's important.</div>

<div><br></div><div>WH: When constructor() is called as a function, super is called as a function too?</div><div><br></div><div>MM: Yes</div><div><br></div><div>WH: What causes the TDZ to appear? The statically visible presence of a super call in the body of the constructor?</div>

<div><br></div><div>AWB: Yes</div><div><br></div><div>WH: What if the super call is inside an arrow function?</div><div><br></div><div>BE: If `Derived` called without `new`? </div><div><br></div><div>AWB: `super()` is called a non-constructor.</div>

<div><br></div><div><br></div><div>WH: super cannot appear in a nested function?</div><div><br></div><div><br></div><div><br></div><div>AWB: they can appear, but... (trails off)</div><div><br></div><div>JM: A related use case is being able to set up stuff on the instance before calling super()</div>

<div><br></div><div>AWB: Show me code that does that, to make sure we don't break that. </div><div><br></div><div>BE: code that doesn't actually use super() won't break, and there is no such code yet</div><div>

<br></div><div>MM: Base is an example of a function that doesn't have a super call (because it can't). On entry, before user code, implicit init this of fresh newly created object. This is a difference from ES5. The "mostDerived" prototype ...?</div>

<div><br></div><div>AWB: this actually isn't a difference from ES5, because there is no super() in ES5</div><div><br></div><div>MM: you are correct</div><div><br></div><div>MM: how do people feel?</div><div><br></div>

<div>JM: It's not an issue with ES5 -> ES6 legacy, it's an issue with ES6 class designs that evolve over time</div><div><br></div><div>YK: my concern is the pedagogy of this approach.</div><div><br></div><div>
MM: the pedagogy is as shown in this slide.</div>
<div><br></div><div>DH: No! It cannot be taught this way.</div><div><br></div><div>BE: let's just let Mark present.</div><div><br></div><div><br></div><div>MM: </div><div>    </div><div>**From Claude Pache**</div><div>

<br></div><div>```js</div><div>F.[[Construct]](args, rcvr)</div><div>```</div><div><br></div><div>- Distinguish functions-which-call-super</div><div>- Vanilla function at end of super-call-chain is base (instantiation postponed to base entry)</div>

<div><br></div><div>**Modifications to Claude's proposal **</div><div>    </div><div>```js</div><div>F.[[Construct]](args, rcvr)</div><div>```</div><div>- mod: Only MOP signature change</div><div>- Distinguish functions-which-call-super</div>

<div>- mod: call-super-as-a-function</div><div>- `super()`, but not `super.foo()`</div><div>- Vanilla function at end of super-call-chain is base (instantiation postponed to base entry)</div><div>- mod: instantiation postponed to base entry</div>

<div><br></div><div><br></div><div>YK: What about subclass constructors that don't include a call to `super()`. </div><div><br></div><div>AWB: Throw when `new`'ed</div><div><br></div><div>Agreement.</div><div><br>

</div><div>JM: I still have issues with state initialization</div><div><br></div><div>YK: Issues</div><div><br></div><div>BE: Concern about setting properties on the instance before `super()`</div><div><br></div><div>JM: Code patterns exist, they won't just go away. </div>

<div><br></div><div>AWB: Can get around it with `super.constructor()`</div><div><br></div><div>BE: Lose the static analysis of `super(` (right paren intentionall omitted)</div><div><br></div><div>MM: </div><div>    </div>

<div>**[[Call]] Traps**</div><div><br></div><div>```</div><div>F(...args) -> F.[[Call]](undefined, args)</div><div><br></div><div>Derive.[[Call]](const this, args)</div><div>  super(...other) -> super.special_name(...other)</div>

<div>```</div><div><br></div><div>WH: What is the special name?</div><div><br></div><div>MM/AWB/DD: (to Waldemar) This is the ES6 spec</div><div><br></div><div>WH: Explain?</div><div><br></div><div>AWB: methods that ref super are bound to an object where the super ref takes place. that binding is the current inst. two bound values object where look up starts and the method name.</div>

<div><br></div><div>MM: </div><div>    </div><div>**[[Construct]] Traps**</div><div><br></div><div>```</div><div>new F(...args) -> F.[[Construct]](args, F)</div><div><br></div><div>Base.[[Construct]](rcvr, args)</div>
<div>
  entry -> const this = [[Create]](rcvr.prototype)</div><div><br></div><div>Derive.[[Construct]](args, rcvr)</div><div>  entry -> TDZ this</div><div>  super(...other) -> const this = super.[[Construct]](other, rcvr)</div>

<div>```</div><div><br></div><div><br></div><div>**Remaining Requirements**</div><div><br></div><div>Am I called as a constructor?</div><div><br></div><div>What is the original's constructor's prototype?</div><div>

<br></div><div>How do I provide alternate instance to the subclasses?</div><div><br></div><div><br></div><div><br></div><div><br></div><div>**Am I called as a constructor?**</div><div><br></div><div><br></div><div>```js</div>

<div>function F(...other) {         </div><div>  let constructing = false;</div><div>  try { this; } catch(_) { constructing = true; }         </div><div>  super(..);</div><div>}</div><div>```</div><div><br></div><div>**Base instantiates proxy scenario**</div>

<div><br></div><div><br></div><div>```js</div><div>function Base(...other) {</div><div>  return new Proxy(... this.prototype ...);</div><div>}  </div><div>```</div><div><br></div><div><br></div><div>**Kill two birds with "new"**</div>

<div><br></div><div>```js</div><div>function Date() {</div><div>  let now = $$GetSystemTime();</div><div>  if (new*) {</div><div>    let obj = Object.create(new*.prototype);</div><div>    // obj@now = now; // private “now” state</div>

<div>    return obj;</div><div>  } else {</div><div>    return ToTimeString(now);</div><div>  }</div><div>}</div><div>```</div><div><br></div><div><br></div><div>MM: Proposing a new special form (shown as `new*` above) whose value is the most derived otherwise undefined. </div>

<div><br></div><div>The test being: reliably check if I am called as a constructor.</div><div><br></div><div>WH: Unless the most derived receiver is falsy. Is there a way to create such a thing?</div><div><br></div><div>
AWB: Yes, you can invoke the reflection trap and specify a falsy value for the receiver.</div>
<div><br></div><div>MM: Modified the above example to:</div><div>    </div><div>    if (new* !== void 0) ...</div><div><br></div><div>AWB: We could fix this by throwing if reflection is used to invoke a constructor with undefined as the receiver.</div>

<div><br></div><div><br></div><div>**Reflection and Proxies**</div><div><br></div><div><br></div><div>- `Reflect.construct(F, args, rcvr)` (throw on undefined)</div><div>- construct trap: `construct: function(target, args, rcvr)`</div>

<div><br></div><div>YK: How does this work in ES5 classes?</div><div><br></div><div>AWB: </div><div>    </div><div>YK: Is conditional super a hazard?</div><div><br></div><div>MM: Yeah</div><div><br></div><div>AWB: New power, new complexity</div>

<div><br></div><div>YK: Exposing something that was implicit into the main path. Calling super in a constructor conditionally?</div><div><br></div><div>EA: Bug, can be fixed</div><div><br></div><div>AWB: (re: Date example) Where it shows Object.create...</div>

<div><br></div><div>DL/AWB: If you conditionally forgot to call `super()`,  [[Construct]] will have to check at exit and throw.</div><div><br></div><div>YK: With @@create you had to know what you were doing. With this you could tread on weird cases without knowing it.</div>

<div><br></div><div>BE: Lets park that discussion for now.</div><div><br></div><div>DL: The sign that TypedArray is giving us is a sign of what user code might do as well so they will have the same issue.</div><div><br></div>

<div>AWB: Better direction. Don't go another decade where implementations can have private slots, but user code cannot.</div><div><br></div><div>MM: The direction I've presented is what I prefer. What I'm _actually_ proposing is that we allow Allen to be the champion and work out the details remaining. Objection?</div>

<div><br></div><div>None. </div><div><br></div><div>BE: No objection, but I want to make sure Allen works with YK, JM and Boris Zbarsky</div><div><br></div><div>#### Conclusion/Resolution</div><div><br></div><div>- Agreement to MM proposal: Allen to be the champion and work out the details remaining</div>

<div><br></div><div>(This did not gain _final_ consensus, as follow up was necessary)</div><div><br></div><div><br></div><div>... On to JM objections</div><div><br></div><div><br></div><div>JM: Start with a class never meant to be subclassed. Later you want to re-use aspects of this class, but need a way to hook in to the subclass `this` before `super()` class. </div>

<div><br></div><div>DH: eg. an `initialize` method that just sets up properties and state</div><div><br></div><div>AWB: If it's just state that it doesn't need to know about, it doesn't matter?</div><div>If it's state that does need to know about, what the channel? Seems very tenuous at best</div>

<div><br></div><div>JM: An example, we want to re-write some of the dom before calling the parent constructor.</div><div><br></div><div>DL: How is dom related?</div><div><br></div><div>WH: Are you unable to munge parameters to constructor?</div>

<div><br></div><div>AWB: Consider a scenario where the DOM mutation is contained in a method of the super class that must be invoked, for side effect, with no dep on object instance state, but is an instance-side method. The way around is to access your prototype or original prototype and invoke the method on the instance</div>

<div><br></div><div>Discussion of legacy scenarios and validity. </div><div><br></div><div>AWB: More of a refactoring issue</div><div><br></div><div>YK/JM: Agreement that we need more real world cases. </div><div><br></div>

<div>MM: Need a very concrete example, showing: the code written that wasn't intended for subclassing and the newer code that's attempting to subclass. </div><div><br></div><div>YK: There are issues created by memoization </div>

<div><br></div><div>Discussion re: subclassing in general. </div><div><br></div><div>MM: Need to do the concrete example exercise, and before the end of this meeting. </div><div><br></div><div>AWB: The fallback is that we just keep what we have. </div>

<div><br></div><div>DD: Worried about @@create, that it won't be possible to subclass because there is negative feedback</div><div><br></div><div>MM: Break on this discussion until JM has adequate examples.</div><div>

<br></div><div><br></div><div>## 5.2 SIMD.JS </div><div><br></div><div>(Peter Jensen and John McCutchan)</div><div><br></div><div><a href="https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/simd-128-tc39.pdf">https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/simd-128-tc39.pdf</a></div>

<div><br></div><div>Other slides: <a href="https://peterjensen.github.io/html5-simd/html5-simd.html#/">https://peterjensen.github.io/html5-simd/html5-simd.html#/</a></div><div><br></div><div>JMC: (introducing SIMD, Single Instruction Multiple Data)</div>

<div><br></div><div>Slide presentation</div><div><br></div><div><br></div><div>Proposing a Fixed 128-bit vector type as close to the metal while remaining portable</div><div>- SSE</div><div>- Neon</div><div>- Efficient scalar fallback possible</div>

<div><br></div><div>Scales with other forms of parallelism</div><div><br></div><div>WH: Why fixed 128, given that x86 SIMD is now up to 512-bit vectors?</div><div><br></div><div>DH: Plenty of real world use cases for this, video codecs, crypto, etc. </div>

<div><br></div><div>STH: Wider widths?</div><div><br></div><div>JMC: Yes.</div><div><br></div><div>AWB: Works with IBM PowerPC?</div><div><br></div><div>JMC: Yes, overlapping instruction sets. </div><div><br></div><div>Proposing, specifically: </div>

<div>    </div><div>- SIMD module</div><div>  - New "value" types</div><div>  - Composable operations</div><div>    - Arithmetic</div><div>    - Logical</div><div>    - Comparisons</div><div>    - Reordering</div>

<div>    - Conversions</div><div>- Extension to Typed Data</div><div>  - A new array type for each</div><div><br></div><div>float32x4, 4 IEE-754 32-bit floating point numbers</div><div>int32x4, 4 32-bit signed integers</div>

<div>float64x2, 2 IEE-754 64-bit floating point numbers</div><div><br></div><div>Float32x4Array, array of float32x4</div><div>Int32x4Array, array of int32x4</div><div>Float64x2Array, array of float64x2</div><div><br></div>

<div>    </div><div>    </div><div>Object Hierarchy</div><div><br></div><div>SIMD</div><div>  -> int32x4</div><div>    -> add, sub, ...</div><div>  -> float32x4</div><div>    -> add, sub, ...</div><div>  -> float64x2</div>

<div>    -> add, sub, ...</div><div>  </div><div>   </div><div><br></div><div>DH: Introduce new value types, but does not depend on user created value types</div><div><br></div><div>JMC: Examples...</div><div><br></div>

<div>```js</div><div>var a = SIMD.float32x4(1.0, 2.0, 3.0, 4.0);</div><div><br></div><div>var b = SIMD.float32x4.zero();</div><div>```</div><div><br></div><div>MM: Why is zero() a function instead of a constant?</div><div>

<br></div><div>JMC: It could be a constant.</div><div><br></div><div>... additional examples. See Slides.</div><div><br></div><div><br></div><div>STH: How much of the difference is SIMD and single precision?</div><div><br>

</div><div>JMC: I don't have numbers, but would say SIMD</div><div><br></div><div>MM: Do SIMD instructions preserve denormals or flush?</div><div><br></div><div>JMC: ARM flush to zero. SSE you can select</div><div><br>

</div><div>**Inner Loop** </div><div><br></div><div>JMC: All high level JS can be stripped down in the JIT</div><div><br></div><div><br></div><div>**Shuffling** </div><div><br></div><div>(copy from slide)</div><div><br></div>

<div>JMC: Compiles down to a single instruction </div><div><br></div><div>WH: There are 256 of those constants defined?</div><div><br></div><div>JMC: Yes.</div><div><br></div><div><br></div><div>**Branching**</div><div><br>

</div><div>(copy from slide)</div><div><br></div><div>WH: What data type used to represent that?</div><div><br></div><div>JMC: int32x4</div><div><br></div><div>WH: Any kind of 4-bit data type for the mask?</div><div><br>
</div>
<div>Q about displayed data on slide </div><div><br></div><div>WH: Is `select` bitwise?</div><div><br></div><div>JMC: Yes</div><div><br></div><div>WH: Cool. It's data type agnostic and lets you slice into smaller bit slices.</div>

<div><br></div><div>WH: Also, those of us who do NaN-coding will need to beware, because this can both view and manufacture arbitrary NaN's.</div><div><br></div><div><br></div><div>**How does VM optimize for SIMD**</div>

<div><br></div><div>(copy from slide)</div><div><br></div><div><br></div><div>**Firefox implementation Status</div><div><br></div><div>(see slide)</div><div><br></div><div><br></div><div>**Chrome/v8 implementation status**</div>

<div><br></div><div>(see slide)</div><div><br></div><div><br></div><div>YK: is Chrome interested in these patches?</div><div><br></div><div>JMC/PJ: They want confirmation from TC39</div><div><br></div><div>DL: This is v8, not chrome. v8 team is fairly conservative.</div>

<div><br></div><div><br></div><div>**Emscripten Implementation Status**</div><div><br></div><div>(see slide)</div><div><br></div><div>JMC: Much of these operations are used in real world platforms written in C++</div><div>

<br></div><div><br></div><div>**V8 SSE Benchmarks (Early 2014)**</div><div><br></div><div>(see slide)</div><div><br></div><div><br></div><div>MM: How can you get faster than 4x faster with 4-way SIMD?</div><div><br></div>

<div>DH: Float 32</div><div><br></div><div><br></div><div>**SpiderMonkey SSE Benchmarks (Early 2014)**</div><div><br></div><div>(see slide)</div><div><br></div><div><br></div><div>**Dart VM NEON Benchmarks (Early 2014)**</div>

<div><br></div><div>(see slide)</div><div><br></div><div>MM: Why are the relative speed ups across the vms are so different?</div><div><br></div><div>JMC: Different output from different code</div><div><br></div><div><br>

</div><div>**Why Fixed Width and not Variable Width Vectors**</div><div><br></div><div>(see slides, 1 & 2)</div><div><br></div><div><br></div><div>STH: A problem bigger than variable width vectors. If we wanted 256 bit widths, on 128 bit vector platforms, observable differences. </div>

<div><br></div><div>JMC: </div><div>    </div><div>    </div><div>WH: Why is intel building hardware with 128 bit vectors</div><div><br></div><div><br></div><div>-- Dmitry Lomov (DL) will fill in details of discussion here. </div>

<div><br></div><div>JMC: this will expose differences hardware </div><div><br></div><div>JMC: no implicit conversions, 1 + <float32x4> will do string concatenation</div><div>MM: why?</div><div>JMC: too much magic</div>

<div>DH & JMC: overloading operators is ok, no lifitng or implict conversions</div><div><br></div><div><br></div><div>WH: It's bad that you can do -<float32x4> but not 2*<float32x4> and instead have to splat the 2 into its own vector first.</div>

<div><br></div><div><br></div><div>JMC: like asm.js, have to be clear about what types you're operating on.</div><div><br></div><div>YK: Don't have to make the ergonomics good</div><div><br></div><div>JMC: Don't have to, they never will be.</div>

<div><br></div><div>**Planned Features 1**</div><div><br></div><div>- SIMD and value objects/types</div><div>  - float32x4 and friend will be value objects</div><div>  - overloaded operators (+, -, ..._ will be mapped to SIMD.<type>.<op> equivalents</div>

<div><br></div><div>- Additional data types (int8x16 and int16x8)</div><div>  - Looking at VP9 encode/decde for justification</div><div>  </div><div><br></div><div>AWB: The top bullet has a lot deps, but the bottom not, are these near term?</div>

<div><br></div><div>JMC: Yes</div><div><br></div><div>WH: Why not int64x2?</div><div><br></div><div>JMC: Support is not universal</div><div>    </div><div>MM: </div><div>- Universal across processors</div><div>- something that has compelling algorithm</div>

<div><br></div><div>Unsigned integers don't fall in the second?</div><div><br></div><div>WH: Why not unsigned integers?</div><div><br></div><div>JMC: Not widely used</div><div><br></div><div>WH: uint32 perhaps, but uint16 and uint8 are heavily used in graphics to represent pixel values.</div>

<div><br></div><div>JMC: tried, issues encountered</div><div>- Extracting kernels and analysing the algorithms they're using and finding the instruction set overlap</div><div>- start with smaller scope, can expand later on. can add x8, x16 later. Surveyed internal teams</div>

<div>- 128 SIMD and expand from there.</div><div><br></div><div>MM: What's being saved, given the already exposed information?</div><div><br></div><div>JMC: time, complexity, etc.</div><div><br></div><div>AWB: How would you specify "slow", "fast", etc.</div>

<div><br></div><div>DH: Leave it undefined. "High recommended if supported, etc"</div><div><br></div><div>AWB: worried about gaming. </div><div><br></div><div>DH: same</div><div><br></div><div><br></div><div>**Planned Features 2**</div>

<div><br></div><div>(see slide)</div><div><br></div><div>DH: Risk:</div><div>    </div><div>- Some content is written such: if optimized, do this, if not, throw an error</div><div>- Browser doesn't want to be left out, will fake the optimized flag.</div>

<div><br></div><div>YK:  The only reason to do the check is if you know you have a faster scalar implementation for systems without the SIMD feature; path of least resistance is to use polyfill and do no check at all. So maybe risk is not so great.</div>

<div><br></div><div>WH: Flip side also could be an issue: Web site has code for the optimized case which is not present on common platforms, somebody changes it and doesn't test it properly, it later breaks on optimized implementations, so browsers don't want to set the optimized flag.</div>

<div><br></div><div>JMC: (confirmed awareness of gaming)</div><div><br></div><div>BE: Some won't fake for fear of the performance cliff. See WebGL precedents.</div><div><br></div><div>Discussion re: risk, generally: some risks worth taking.</div>

<div><br></div><div><br></div><div>WH: instead of boolean, maybe a value that indicates speed level?</div><div><br></div><div>AWB: Application could do a mini benchmark as a test?</div><div><br></div><div><br></div><div>
<br>
</div><div><br></div><div>**Stage 1 Ready?**</div><div><br></div><div>(see slide)</div><div><br></div><div>AWB: Sounds like it is ready for stage 1. Can it be its own independent standard?</div><div><br></div><div>WH: It creates new primitive data types. Don't want specs outside creating new types </div>

<div><br></div><div>AWB: Do you expect every runtime to implement this?</div><div><br></div><div>JMC: Yes. They will run to implement this!</div><div><br></div><div>BE: Some embedded systems have trouble ith regex and unicode, it's expect that there will be "code commerce" among distinct device classes' embedded runtimes. </div>

<div><br></div><div>MM: We need a general framework for new value types</div><div><br></div><div>AWB: Without the value types, it's fairly clear cut. </div><div><br></div><div>MM: Preserving reference identity makes it prohibitively expensive</div>

<div><br></div><div>DD: Per the ES7 model, the feature can progress without being in another spec. </div><div><br></div><div>Discussion of the spec process.</div><div><br></div><div>STH: Back to MM statement, what does typeof have to do with reference identity?</div>

<div>- Could be implemented by memoizing the identity, not that you'd implement that way</div><div><br></div><div>MM: (example of using a weakmap)</div><div>- Logically, if they're a reference type, we have to admit them to WeakMaps, if they are a value type we can reject them. I hadn't considered the memozation</div>

<div><br></div><div>AWB/DH: (clarification of coupling and timing issue) </div><div><br></div><div>DH: Needs to be the same semantics as value types, if we ship this sooner and learn that we made a wrong call, then we have to deal with deciding whether or not we apply the mistake or break with SIMD. </div>

<div><br></div><div><br></div><div>#### Conclusion/Resolution</div><div><br></div><div>- Moves to stage 1</div><div><br></div><div><br></div><div><br></div><div>## 4.3 Function parameter/let declaration name conflict rules </div>

<div><br></div><div>(Allen Wirfs-Brock)</div><div><br></div><div><a href="https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/parameter-scoping-7-14.pdf">https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/parameter-scoping-7-14.pdf</a></div>

<div><br></div><div><br></div><div>Current spec, Controversial: </div><div><br></div><div>```js</div><div>function(x) {</div><div>  var x;</div><div>  let x; // early error    </div><div>}</div><div><br></div><div>function(x) {</div>

<div>  let x; // early error    <--------</div><div>}    </div><div><br></div><div>try {</div><div>} catch(x) {</div><div>  let x; // early error    <--------</div><div>}</div><div>```</div><div><br></div><div>AWB: Andreas wants consistent handling</div>

<div><br></div><div>DH: The mental model is that let is block-bound, </div><div><br></div><div>DH: `var` is "I assert there is a binding in this scope, but that can be re-asserted as much as I want". `let` is "I have one unique declaration, I don't allow redeclaration".</div>

<div><br></div><div>YK: If you say `var x = 42` half way down the function, you can use the original parameter `x` until that point. With TDZ, if you had `let x = 42` half way down, you couldn't mean anything with `x`</div>

<div><br></div><div>DD: (points about let and const protecting from mistakes)</div><div><br></div><div>BE: (channeling Andreas) Worried that there will errors when you want to shadow. </div><div><br></div><div>DH/YK: The shadowing is meaningless. </div>

<div><br></div><div>MM: I was indifferent, but side with Dave's points about refactoring</div><div><br></div><div>STH: Generating code via macros, introduces non-local restrictions that could break </div><div><br></div>

<div>DH: Just have a notion of parameter bindings and block bindings, distinct from the surface syntax, and latter can't shadow former; easy workaround for code generators is to add an extra pair of `{ }`.</div><div>
<br>
</div><div>MM: (example of user blindly changing `var` to `let`)</div><div><br></div><div>STH: This isn't a language issue, it's a non-semantics preserving change.</div><div><br></div><div>DL: (on behalf of Andreas)</div>

<div><br></div><div>For Do-Expressions:</div><div><br></div><div>```js    </div><div>() => {} = () => do {}</div><div>```</div><div><br></div><div>DH: Doesn't hold b/c left is statement body, right is expression body, not equivalent.</div>

<div><br></div><div>AWB: (revisting decisions about duplicate declarations in same contour)</div><div><br></div><div>AWB: Need to ensure that lexical declarations are disjoint sets, there spec mechanics there.</div><div>
<br>
</div><div>STH: Proposing </div><div><br></div><div>RW: The refactoring hazard only exists for the one time the code is run after the change from `var` to `let` and the refactorer is shown the early error and immediately knows to fix the bug. Removing these errors is unfortunate</div>

<div><br></div><div>YK: It's not clear what the program does when there is no early error. </div><div><br></div><div>RW: What is Sam's position?</div><div><br></div><div>STH: Why do we have these errors? What do we gain from them? </div>

<div><br></div><div>RW: Arguably, JavaScript could use some degree of "nannying" if it has positive results.</div><div><br></div><div>MM: No way to explain that function declaration initializes the parameter?</div>

<div><br></div><div>BE: It doesn't. Andreas just wants `let` to behave like `var` re: redeclaration</div><div><br></div><div>MM: Strict programming should be understandable in terms of lexical scope. </div><div>1. Parameters and body are two scopes</div>

<div>  - If explain as two scopes, can't unify. </div><div>2. One scope</div><div>  - Has to be an early error.</div><div>  </div><div>  </div><div>BE: Good argument, but not sure it depends on strict.</div><div><br>
</div>
<div>MM: In sloppy mode, functions are crap as well.</div><div><br></div><div>STH: He's just trying explain the semantics of `let`, w/r to block scope alone.</div><div><br></div><div>MM: A `var-less` strict program should be understandable in terms of lexical scope. </div>

<div><br></div><div>BE: `var` is huge turd that should be recalled into some lesser demon's bowels.</div><div>- We want the error. </div><div><br></div><div><br></div><div><br></div><div>#### Conclusion/Resolution</div>

<div><br></div><div>- Status Quo</div><div>- DDWIDM: "Don't Do What I Didn't Mean"</div><div><br></div><div><br></div><div><br></div><div><br></div><div>## 4.7 Revisit Comprehension decision from last meeting.</div>

<div><br></div><div>(Allen Wirfs-Brock)</div><div><br></div><div>AWB: There are a lot of TC members and non-members concerned that this was not a wise decision and that we should revisit. Included link to Andy Wingo</div>

<div><br></div><div>RW: if I had been here at the last meeting I would've objected to the removal, but as I told Dave offline, I trust him and his plans for syntax unification. I just wanted to see progress in that regard. </div>

<div><br></div><div>BE: I want to say: I was the champion for years, but letting go. I want to see the comprehensions laziness addressed.</div><div><br></div><div>DH: I did this exercise, the sudoku solver in:</div><div>
    </div>
<div>- pythonic</div><div>- linq style</div><div>- no comprehensions</div><div><br></div><div><a href="https://github.com/dherman/sudoku">https://github.com/dherman/sudoku</a></div><div><br></div><div><br></div><div>JH: I'd like to know if there are objections still, to deferral</div>

<div><br></div><div>AWB: Objecting to the late removal of a complete feature. </div><div><br></div><div>RW: Same objection, reached independantly, but again I trust Dave to see through the syntax unification.</div><div><br>

</div><div>DH: First, laziness is not a problem; you just need a way to construct a lazy sequence either from an eager value (`array.lazy()`) or from whole cloth (`lazyRange(0, 1000)`).</div><div><br></div><div>DH: Second, the fact that comprehensions only do a subset of operations you want means you end up mixing code styles (comprehensions + methods), and it gets syntactically awkward.</div>

<div><br></div><div>DH: When I did the exercise with three styles, I found the generalized comprehensions nicer but no comprehensions at all nicest.</div><div><br></div><div>BE: The affordance of generator expressions and comprehensions is that you don't have to write a call</div>

<div><br></div><div>DH: (Gives walk through of solver.linq.js, solver.pythonic.js)</div><div><br></div><div>- The exercise shows a need for new methods of iterators, flatMap, filter, etc. </div><div><br></div><div>DH: I said last time that we need an Iterator.prototype object and we agreed to defer since it probably wouldn't break code, but we forgot that hurts polyfills that want to patch the prototype with upcoming standard methods. So we should add the empty prototype object in ES6.</div>

<div><br></div><div>WH: In expressions such as foo.lazy().map(...function1...).every(...function2...), what shuts down (i.e. calls the return method of) the foo.lazy() generator?</div><div><br></div><div>DH: The call to every will shut down the generator if it reaches its decision early.</div>

<div><br></div><div>DD: The minimal Iterator.prototype is empty, but available. The long term is a constructor Iterator with blessed apis. </div><div><br></div><div>DH: Confirm</div><div><br></div><div>BE: An actual Iterator is means Duck typing isn't the preferred way, just create a real Iterator</div>

<div><br></div><div>MM: Using an actual functional style, the function names you're using are </div><div><br></div><div>BE: The oop style prevails, desired chaining API, adapter full of goodies.</div><div><br></div><div>

Discussion of generators and observables</div><div><br></div><div>WH: How would you represent a 2-d comprehension like (for (x of xs) for (y of ys) if (x % y) x+y)?</div><div><br></div><div>xs.flatMap(x => ys.filter(y => x % y).map(y => x+y))</div>

<div><br></div><div>WH: OK. A bit less pretty than the comprehension in this case, but acceptable.</div><div><br></div><div>MM: after seeing this code I will never use comprehensions</div><div><br></div><div>YK: *raises arms in triumphant vindication*</div>

<div><br></div><div>BE: who will own explaining to Andy Wingo and es-discuss?</div><div><br></div><div>DH: I will</div><div><br></div><div>BE: "You keep what you kill" - Richard P. Riddick</div><div><br></div><div>

#### Conclusion/Resolution</div><div><br></div><div>- Add a prototype for iterators, but do not expose a global Iterator constructor for ES6 (leave that for ES7)</div><div>  - Between Object prototype and Generator prototype</div>

<div>  - Initially empty, but accessible</div><div>- Comprehensions in general deferred to ES7</div><div><br></div><div><br></div><div><br></div><div>## 4.12 Revisit spread and destructuring of string </div><div><br></div>

<div>(Erik Arvidsson , Brendan Eich)</div><div><br></div><div>EA: We're using ToObject in spread and all other iterable forms. Should we do the same for destructuring?</div><div>- This would allow destructuring strings and other non-objects.</div>

<div><br></div><div>```js</div><div>// Should allow: </div><div>let [first, ...rest] = "foo";</div><div>first; // "f"</div><div>rest;  // ["o", "o"]</div><div>```</div><div><br></div>

<div>STH: ToObject breaks pattern matching because you couldn't match on a number.</div><div><br></div><div>YK: But we agreed to a future irrefutible matching, which would be the basis of pattern matching. </div><div>

<br></div><div>DH: Array vs. Object cannot have the same semantics here in what we want from pattern matching</div><div>- if I used an array</div><div><br></div><div>EA: Uses iterator</div><div><br></div><div>DH: Not even self-evident that pattern matching syntax will work in JS</div>

<div><br></div><div>YK: (to Sam) Do you think it will it should fail for strings to destructure?</div><div><br></div><div>More discussion of pattern matching. </div><div><br></div><div>DH, BE: match must mean a different pattern language, ships have sailed for destructuring and implicit ToObject</div>

<div><br></div><div>#### Conclusion/Resolution</div><div><br></div><div>- Destructuring does ToObject</div><div><br></div><div><br></div><div>## 4.5 Import-into-namespace syntax (Dave)</div><div><br></div><div>(Dave Herman)</div>

<div><br></div><div>request slides</div><div><br></div><div>DH: (recapping the last meeting and the findings of the breakout group; and the fall out)</div><div><br></div><div>DH:</div><div>    </div><div>**Resolution**</div>

<div><br></div><div>- Changed syntax for clarity</div><div><br></div><div>(need slides)</div><div><br></div><div><br></div><div><br></div><div>**Module Context 1**</div><div><br></div><div>- Existing systems provide contextual metadata: </div>

<div>  - <a href="http://module.id">module.id</a></div><div>  - __filename</div><div>  - __dirname</div><div><br></div><div>- What is the dynamic analog of relative import?</div><div><br></div><div>```js</div><div>import helper from "./helper";</div>

<div>```</div><div><br></div><div><br></div><div>**Module Context 2**</div><div><br></div><div>- no implicit namespace pollution, plz</div><div>- JS has a dedicated contextual variable: `this`</div><div>- Solution: inital `this` binding is a context object</div>

<div><br></div><div><br></div><div>DD: How is this different from adding global variables, eg. `Reflect`</div><div><br></div><div>STH: The difference is that the value depends on where it is; unlike `Reflect`, which is the same thing. </div>

<div><br></div><div>DH: We should use `this` in top level of a module</div><div><br></div><div>AWB: what does that mean? `this` at the top level of a module?</div><div><br></div><div>DH: </div><div>    </div><div>**Module Context 2**</div>

<div><br></div><div>- Relative import: </div><div>```js</div><div>this.import("./helper").then(...);</div><div>```</div><div><br></div><div>- Space for host-specific contextual metadata: </div><div>```js</div><div>

this.filename</div><div>```</div><div>(This is where platforms can put its host properties and objects)</div><div><br></div><div><br></div><div>- Cross-talk about `eval` </div><div>- `Reflect.global`</div><div><br></div>
<div>
BT: indirect eval?</div><div><br></div><div>DH: Will give you the global object</div><div><br></div><div>DD: object to relying on `this` outside of a method</div><div><br></div><div>RW: Workers already to the above</div>
<div>
<br></div><div>MM: We can't even poison `this` for ES6</div><div><br></div><div>YK: if you says it's module context, you have to say how it got that value</div><div><br></div><div>DH: No new scoping rules. This construct just implicitly binds something. </div>

<div><br></div><div><br></div><div>AWB: </div><div>```js</div><div>import filename from this;</div><div>// which basically: import filename from here;</div><div>```</div><div><br></div><div>DD: Like this for relative</div>

<div><br></div><div>DH: Completely amenable to this</div><div><br></div><div>YK: </div><div>```js</div><div>import * as me from here;</div><div>me.import; // `me` is the context object</div><div>```</div><div><br></div><div>

<br></div><div><br></div><div><br></div><div><br></div><div>#### Conclusion/Resolution</div><div><br></div><div>- the api is right direction</div><div>- each module gets its own version of that object</div><div>- need some sort of access to the module contextual object</div>

<div>- some sort of declarative form to get at </div><div>- static contextual information about the module</div><div><br></div><div><br></div><div><br></div><div><br></div><div>"Then, during the Third Reconciliation of the Last of the Meketrex Supplicants, they chose a new form for him, that of a giant Sloar! Many Shubs and Zulls knew what it was to be roasted in the depths of a Sloar that day, I can tell you!" </div>

<div>―Vinz Clortho[src]</div><div><br></div></div>