September 23, 2014 Meeting Notes

Brian Terlson (BT), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jeff Morrison (JM), Jonathan Turner (JT), Sebastian Markbåge (SM), Erik Arvidsson (EA), Brendan Eich (BE), Domenic Denicola (DD), Peter Jensen (PJ), Eric Toth (ET), Yehuda Katz (YK), Dave Herman (DH), Brendan Eich (BE), Simon Kaegi (SK), Boris Zbarsky (BZ), Andreas Rossberg (ARB), Caridy Patiño (CP), Niko Matsakis (NM), Mark S. Miller (MM), Matt Miller (MMR), Jaswanth Sreeram (JS)

Remote: István Sebestyén (IS)

Welcome

RW: (explanation of evening meetup)

TC39 expresses its appreciate to Bocoup for hosting and ECMA for dinner.

JN: Adoption of agenda?

Approved: https://github.com/tc39/agendas/blob/master/2014/09.md

JN: Approval of minutes (July 2014)

Conclusion/Resolution

4.1 Spec status report

(Allen Wirfs-Brock)

tc39-2014-047

AWB:

Issue:

Should %IteratorPrototype% define an @@iterator method?

DD: This supports the established convention

YK: There was objection from Jafar DH: but that was to iterator as self-iterable in whole, not this Iterator.prototype which we want

AWB: (summary in slides)

AWB: Things being removed should be added to https://github.com/tc39/ecma262

EA: @@unscopables shipping in v8 (needed for Array.prototype.values)

AWB:

16.1 Forbidden Extensions

AWB: Mark's concern was stack walking capabilities

DH: At odds with proper tail calls

AWB: In ES5 we added things to spec PTC

YK: Of note: the new JDK's JavaScript engine is claiming to be "spec compliant", but implements racy threads.

DH: Most of the algorithms will fall down because they're not designed for threaded environments

Should Ecma-262 section 16 say something about cases like this?

AWB: We can express the "intent", that these are meant to be run atomically

DH: Memory models are hard.

ARB: Just say something informally to the effect that all algorithms in this spec are assumed to be executed atomically, i.e., are never observably interleaved with, or concurrent with, any other mutation of the programs state.

ARB: What specifically does "Extensions" refer to?

AWB: Specifically the definition in 16, bullet 2.

AWB: w/r to Mark's concerns, we may want to specifically say that we don't want implementors to implement stack walking outside of devtools.

AWB: Open work items:

AWB: Is anyone interesting in analysing the changes in ES5 to determine things that may have been wrong and need to be rolled back?

RW: Should reach out to Mathias Bynens

AWB: Ideally someone willing to become fully aware of the issues and propose/execute on solutions (if necessary)

AWB: Outline of final spec review process from January through June.

JN: Confirm RFTG opt-out

RW: July discussion

Conclusion/Resolution

4.3 Legacy Decimal Integer Literals starting with 0 and containing 8 or 9.

(Allen Wirfs-Brock, Jason Orendorff, Boris Zbarsky)

https://mail.mozilla.org/pipermail/es-discuss/2014-August/038596.html

AWB: Octals beginning with 0 are restricted in strict mode

BZ: Credit card and telephone numbers

AWB: Dates

AWB: In non-strict, where 0 normally means an octal, unless it contains an 8 or 9.

MM: Any program that relies on this will break

> 055 
45 
> 089 
89 
> 051082 
51082 
> (051082).toString() 
"51082" 
> (051078).toString() 
"51078" 
> (051077).toString() 
"21055"

(Discussion about use of broken features)

MM: Want to preserve the restriction as currently written in strict mode. Strict mode program, testing during August, evals 08 will pass, in January it will not.

AWB: Any browser incompatibilities?

BZ: Anyone writing strict mode code won't be writing code like this. For strict mode there is no hazard.

AWB: For Annex B?

BZ: Pull

MM: All strict mode behaviour is normative

AWB: + Annex B

Discussion re: EscapeCharacter

https://bugs.ecmascript.org/show_bug.cgi?id=3212

BE: It was changed in ES3 to use DecimalDigit (from ES1's OctalDigit), would need to ask Waldemar

Conclusion/Resolution

4.4 Number('0b0101'). NaN or not?

(Erik Arvidsson)

EA: Previous discussion, April 2014

Should Number be able to parse the string "0b0" or "0o1"

(Discussion of people (ab)using Number for converting user input and whether this should affect things.)

Yes.

Conclusion/Resolution

4.5 More Function-in-Block

(Brian Terlson)

BT: (covers current spec)

AWB: Exactly the strict modes semantics of functions in blocks

BT: Don't hoist past/up-to nearest function

New issue: 

if (cond) {
  function F() {}
  function G() { F() }
}
// sometime later
if (cond) {
  function F() {}   
}
G();

In today's semantics, when G(); is called, it calls the second F();. In the new design, it would be the first, which is a breaking change. This code actually exists in some ad code somewhere.

BT: No one else has implemented this yet, need to know if IE will be out there alone, or will other browsers stand with IE and break that unusual ad code?

DH: If v8 and spidermonkey post bugs that indicate the intention to implement, then it shows support among implementors and is valuable.

Conclusion/Resolution

Intro to Matt Miller from IETF (Liaison manager)

MMR: (Role as liaison from IETF, to establish a productive relationship, specifically w/r to JSON)

AWB: IETF Documents, eg. JavaScript mimetype references to ES3. Far behind considering ES5 and soon ES6

MMR: The RFCs are stable documents. When a document receives a number, it's set. If it needs to be updated, it can be replaced.

Discussion about interoperability and incompatibility breaks.

Conclusion/Resolution

Revisiting 16.1, Forbidden Extensions

MM: SpiderMonkey removed own caller and own arguments from all function forms ... Needs to be clear: if the this binding is strict or built-in.

AWB: interpret: If it isn't a non-strict function, it behaves exactly as spec'ed.

Discussion of strict/non-strict w/r to built-ins

MM: Applied to anything other than a non-strict function?

(10 minute back and forth about the definitions of "strict function" and "ECMAScript function")

MM's overall concern is to make sure the behavior is nailed down for built-ins as well as for strict functions.

Somehow we started talking about Test262

Discussion of Test262's (lack of) coverage.

BT: We didn't have coverage in Test262 of a non-enumerable property shadowing an enumerable property.

JM: it would be good to have a place to list the open coverage holes.

SK/DD: while reviewing sections of the spec, people should write down a list of test cases that should be written (e.g. https://github.com/domenic/Array.prototype.contains/issues/1 )

AWB: Perhaps we should try to get a rough statement of what our coverage areas are. Some areas are covered because they were in ES3 tests; Microsoft contributed a lot of standard library tests; there are probably lots of gaps.

(Discussion of running Test262 tests against implementations, especially given their optimizations.)

YK: ideally we should not run the tests in interpreted mode.

AR: there is no hot code in Test262, so right now we only run in interpreted mode.

YK: could we use switches to turn up optimizations?

AR: there are complications that in V8 at least make that unlikely to be useful.

(Back to topic of a statement of coverage)

AWB: I'm mostly interested in whether there is a useful set of tests for most areas of the spec

BT: was this the Test262 agenda item?

BE: this was the "depress the room" agenda item

DD/BT: (discussion of poisoning built-ins before running tests)

YK: Value of poisioning?

BT: Implementations have to take care to not rely on user modifiable built-ins.

Conclusion/Resolution

Test262 Update

(Brian Terlson)

BT: A number of PRs remain open from the Test The Web Forward event: people haven't signed CLA despite request, haven't updated patch according to review feedback. These will be closed.

DD: Have two official runners?

DD/BT: Deprecating the python runner?

ARB: Have to check with testing infrastructure

DD: But can we "deprecate", in the

BT: Move all tests from present locations to new homes in new directory heirarchy

AWB: As tests are updated, they could be moved?

BT: confirm

BT: who moved the ES3 tests to ES5 organization?

MM: that was me

BT: that was fun?

MM: I have experienced traumas in my life that were less fun

(Discussion of whether we should move the ES5 stuff piecemeal, e.g. as they get fixed.)

BT: It might be OK to move by feature, e.g. all the Array.prototype.forEach tests could move at once.

(Discussion of how to incorporate post-ES6 tests into the repo, as they are written, but before ES6 tests are finalized.)

AWB: when running "the ES6 test suite," it should only be things that are officially in ES6. But the JS community cares about what they can use in a browser. We should not create impressions that things are done or stable until they have worked through the process.

AR: so we should put experimental things into a separate directory

YK: no. You don't do that in Chrome; you use feature flags.

(Discussion of folder vs. feature flags for new Test262 tests for post-ES6 experimental features.)

AWB: ok with stage 3 being in the repo

DD: needs to be stage 1 and onward

AWB: At stage 1, it's just the champion

BT: Prerequisite to stage 3: have a PR open with your test

DD: Just need a way to flag something as experimental

BT: Accept Allen's proposal?

DD/YK: nooooo

ARB: Fine to have early stage features, as long as they're not intermingled.

BT: The file system isn't ideal.

(Discussion of whether to accept stage 1 onward into Test262.)

DD: Want to make Test262 writing easy, so will be adding helpers.

Conclusion/Resolution

5.1 Trailing Commas in Function Call Expressions and Declarations

(Jeff Morrison)

JM: Useful for diffs in version control systems, especially Git blame. In other languages they often do a comma at the end of each line. We do for commas too.

BE: arrays aren't parameter lists. What other languages allow this?

JM: Python, D, Hack, probably others

JM: you don't have to do this if you don't want to; it's easy to lint for...

MM: just use comma-first style?

JM: doesn't work well for the first argument

AWB: What about rest parameter position? Should it be a syntax error after a rest param?

JM: Hadn't thought about it. No strong feelings. Makes sense to me to be invalid after a trailing rest param

function f(
a, 
b, 
...c
    ) {
return 1;        
}

MM: what's the argument against this?

JM: if people use this, old engines won't be able to run that code.

AWB: it's the "no new syntax" argument.

BE: the funny thing is in C you can't have enums with trailing commas but you can have them in array and struct initializers. That was a botch.

Conclusion/Resolution

BE: let's sleep on it

?.? Process

AWB: When something reaches stage 1 we should create a repo at TC39. And use that issue tracker for discussion instead of es-discuss or bugs.ecmascript.org or other ad-hoc locations.

5.2 Flush denorm to zero

(Allen Wirfs-Brock)

https://mail.mozilla.org/pipermail/es-discuss/2014-June/038029.html https://bugzilla.mozilla.org/show_bug.cgi?id=1027624#c30

AWB/BE: Explanation of "flush to denorm"

https://en.wikipedia.org/wiki/Denormal_number

Denorm values appear in audio algorithms. Modes exist to prevent producing denorms.

MM: Not just wasted precision:

|-|-|-|-------|-------|-|-|-|
      ^       0       ^
largest               smallest 
negative              positive
normal                normal

AWB: Specifically desirable from people writing audio algorithms in JavaScript.

BE: 

Math.denormz(x);
Math.fdenormz(x);
Math.fdenormz(x) === Math.denormz(Math.fround(x));

PJ: Another suggestion to have an FPU mode-setting function?

BE/AWB: That's the big red switch.

BE: Leads to all black-box/other-module functions needing save/restore advice around calls from your module

Conclusion/Resolution

5.3 ArrayBuffer.transfer

(Brendan Eich, Allen Wirfs-Brock for Luke Wagner)

https://gist.github.com/andhow/95fb9e49996615764eff

AWB: (summarizes rationale)

(Discussion re detaching, immutability, freezing, and how they may or may not be related)

BE: ArrayBuffer.transfer seems safe, considering.

Discussion of whether it should be static on ArrayBuffer or a method on the prototype - it's an alternative constructor

Suggestion that ArrayBuffer.transfer(b1, 0) return a zero-length b2, not null. Consensus favors.

AWB: Subclass of ArrayBuffer? What is the class of the object returned by transfer(...)?

Conclusion/Resolution

5.6 NoSuchProperty built-in proxy

(Brendan Eich for Nicholas C. Zakas)

BE: Want to be able to throw if a property access occurs for something that doesn't exist.

var NoSuchProperty = Proxy({}, {   
  has(target, name) {     
   return true;   
  },   
  get(target, name, receiver) {      
    if (name in Object.prototype) {        
      return Object.prototype[name];     
    }     
    throw new TypeError(name + " is not a defined property");   
  } 
});

BE: JS1 was a rush, didn't have time for try/catch, so I was very shy about errors. This should be something that can be made an error. Too much fail-soft where things should've error'ed.

MM: If it's doable in library code, then we should wait until we see more activity.

YK/DD/RW: There are more Proxy related patterns that would more valuable to address before NoSuchProperty, considering it's possible in library code.

DH: (comments on likelihood of actual use)

BE: This will be slow

BZ: It will be fine until you hit the Proxy, based on real engine DOM (nodelist etc.) experience.

Conclusion/Resolution

5.8 Exponentiation Operator Update

(Rick Waldron)

RW: Presenting updates to feature proposal:

Progress to Stage 2?

Confirm.

Conclusion/Resolution

5.5 Math.iaddh, etc. polyfillable 64-bit int helpers

(Brendan Eich for Fabrice Bellard)

https://mail.mozilla.org/pipermail/es-discuss/2014-July/038307.html
https://gist.github.com/BrendanEich/4294d5c212a6d2254703 (Internet Archive)

MM: Recognizes "bigit" as good for bignum big decimal etc. digit, not just for int64 emu

(http://hackage.haskell.org/package/double-conversion-0.2.0.6/src/double-conversion/src/bignum.cc (Internet Archive),
http://code.ohloh.net/file?fid=J9lbBTlP__EhaF2Zrwq6Sk38lZE&cid=891oM4GeZTE&s=&fp=282835&mp&projSelected=true#L0 )

Concrete proposal: 

Math.imulh();
Math.imuluh();
Math.iaddh();
Math.isubh();

Conclusion/Resolution