April 9, 2014 Meeting Notes

Doug Crockford (DC), Brian Terleson (BT), Luke Hoban (LH), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Hudson (RH), Rick Waldron (RW), Eric Ferraiuolo (EF), Jafar Husain (JH), Jeff Morrison (JM), Seo-Young Hwang (SYH), Mark Honenberg (MH), Caridy Patiño (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip Pizlo (FP), Norbert Lindenberg (NL), Sebastian Markbåge (SM), Mathias Bynens (MB), Rafeal Weinstein (RWN), Jaswanth Sreeram (JS), Alex Russell (AR), István Sebestyén (IS), Mark S. Miller (MM), Tatiana Shpeisman (TS), Brandon Benvie (BB), Brendan Eich (BE)

RF Status

(John Neumann)

The May version of the specification is the opt-out version

See: http://www.ecma-international.org/memento/TC39%20policy/Ecma%20Experimental%20TC39%20Royalty-Free%20Patent%20Policy.pdf (E.4-E.6) http://www.ecma-international.org/memento/TC39%20policy/Opt%20Out%20Form%20for%20a%20TC39%20Royalty%20Free%20%28RF%29%20Task%20Group%20%28TG%29.pdf


RF/TG Item

(John Neumann)

JN: Vote to request lifetime membership waiver for Brendan Eich

Motion to approve? [WH raises motion] Yes, seconded

No discussion, No objection


Object.observe Update

(Rafael Weinstein)

RWN: The next step was spec text review.

YK: Reviewed but have feedback

AWB: Concerned not enough attention from committee members

YK: Similar concern, but additionally want to see more practical application testing of new features in general.

AR: Can you be more concrete, with regard to Object.observe

YK: There is a need for filtering of change records

RWN: We had hoped to work on this post 1.0

YK: We tried this and it's messy and complicated, so it's either a matter of being messy and complicated in user code or in V8

LH: Valid and being addressed... How does this correlate to the status of the spec.

YK: The spec seems fine, but this is an issue discovered when I tried to make something with it.

LH: More effort has gone into review of this feature than any other

YK: But needs to be useful to library code.

AWB: (continuing) I'd feel more confident if more committee members reviewed the spec for correctness.

RWN: What is the purpose of the reviewer role, in this stage? I assumed it was for the mechanics, not the feature itself. I'm confident we can work through the existing concerns.

YK: I think that practitioners need to be given an opportunity to review in real use

RWN: This should be done much earlier in the process.

JH: How long is needed to feel comfortable with this?

YK: We already made implementation attempts and ultimately view them as failures. We wrote real code and discovered real problems.

LH: So you're not comfortable giving consensus at this point, based on your actual experience. ...Concern that consensus blocking this late

RWN: Propose that we don't move to stage 3, but I want a commitment from Yehuda that to prioritize working through the remaining issues.

YK: Confirm

RWN: We should view this as feedback for the new process

YK: There was feedback, but no action

RWN: There have been many updates and if there were issues, that was on you to follow up... If there is criticism, it needs to be on record.

AWB: In addition to meeting notes record, file bugs to track progress

YK: In general, if there are concerns, there’s two sides: person A thinks “I should push harder” vs. person B saying “that’s fine” without giving it much thought

AWB: Still need to be more active reviewing in the committee.

Relevant: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-19.md#7-objectobserve-status-report (incomplete notes about the discussion about filtering in general)


Royalty Free Status

(István Sebestyén)

JN: (recaps decisions)

IS: Issues:

  1. Status of Third Party contribution

AWB: Will the forms be available prior to the conclusion of the ballot?

IS: Yes, will make available as soon as we can.

AWB: We have a back log of contributions waiting to be accepted. Would like to be able to provide immediate instruction

  1. IPR has prepared FAQ addressing Ecma copyright policy
  1. Liason with IETF

  2. JSON

AWB: The first edition is done, no sign of interest for a second edition.

IS: Fast track ISO?

(will follow up)

RW: István, please send link to FAQ for inclusion.


BT: CLA needs to be electronic and checked automatically for each pull request (bot)

RW: Needs to provide access to committee members to confirm contributor agreement.

EF: Is the vote for just the forms/agreements?

AWB: The vote is to approve the policy, the forms already exist.


Parallel JS Spec Report

(Rick Hudson)

Slides: TC39PJSApril2013.pdf

RH: Summary

Design Goals

Platorm Independent

Extracting reasonable performance out of parallet hardware

Key Insight: Temporal Immutability

→ The sweet spot between Functional and OO

WH: Examples of whitelisting?

RH: Math.sin

WH: Calculating the sine might be parallelizable, but are the lookup of the name and object used to invoke it parallelizable? My biggest concerns are with the glue stuff such as variable and object accesses, which might hit a proxy, observer, or whatnot.

RH: It’s a QoS issue. Start with everything blacklisted, then let implementations figure out what to optimize/whitelist.

WH: If I dont know what the impl does, what am i allowed to do to stay in this efficient realm

NM: Building tools that will help developers see what operations are causing de-opts, general jit feedback

MM: With the JIT optimization, you're comfortable knowing the jit will do its job

WH/YK/MM/AR: (Disagreement)

AR: I maintain a hierarchical constraint solver and must pay close attention to keeping math operations on the same numeric path (note: maintaining values as integer or float)

NM: For best performance, parallel code wants to do the same. We expect better developer tools will be very helpful for both cases.

WH: I want to know specifically how to stay within the good performance safe-harbor

NM: Yes, but we don't have a complete picture.

WH: Want at least a safe harbor subset described. Having users study the idiosyncrasies of a specific implementation to discover it just leads to fragmentation.

TS: Recommend best practices document, vs. specification text

WH: Standards can clearly suggest. For example, the C++ standard has done that by naming the safe harbor conditions that allow the RVO and NRVO optimizations. Implementations can go even further than the cases named in the standard, but users can expect to have at least those optimization cases work efficiently.

NM: I can see an addendum that includes this, but we're not there yet. It takes time to figure out what the common subset is. I expect we'll eventually be able to say this with more precision.

WH: Where on the spectrum between stylized mostly machine-generated code (asm.js) and general-purpose user-written code can we expect the optimizable subset to be?

NM: Much closer to general purpose user-written code.

RH: There will be a sweet spot where this will be very effective. Progress will show

RH: (continuing)

Parallel JavaScript API (ES7)

(Need slide)

Sum using reducePar

// Sequential
var i;
var a = [1,2,3,4];
var sum = 0;
for (i = 0; i< a.length; i++) {
  sum+= a[i];
// Data Parallel
var pa = [1,2,3,4];
... need slide.


var pa = Array.buildPar(4, i => i);
var reversed = pa.scatterPar((a, index, c) => c.length - index - 1); // [3,2,1,0]


var pa = [1,-7,3,5];
var positive = pa.filterPar(e => e > 0); // [1, 3, 5]

WH: Is there a similar thing to (common lisp) mapcan? [In Common Lisp mapcan is a map which calls a function on each element. The function returns a list and mapcan returns the concatenation of those lists. The JS equivalent would be the same except using arrays instead of lists.] When writing code I found mapcan to be one of the most useful mappers.

NM: We don't currently have a flatMap operation. It can be done in parallel but requires multiple passes. Could be done in user code.

WH: Doing it in user code makes it hard to optimize well. A built-in would offer more opportunities for an implementation to optimize it by expressing what the user is doing much more directly.

NM: Let's follow up off line

LH: I've noticed that these are all defined on arrays, but used to be on Typed Array

NM: On both

LH: These are consuming and producing arrays, is there a lot of overhead? You'll have an allocation

DL: (Dmitry, please fill in)

NM: The API is important, but we haven't worked on it.

RH: (continuing)


(see slide)

MM, WH: Why do the arrows on the slide cross? Why require reduce combinators to be commutative?

NM: For parallelism.

MM, WH: Why? Only associative is needed for parallelism.

TS: eg. if you try to do addition, 100 threads on GPU and doing addition as atomic operation, can’t guarantee commutativity

WH: If you're able to compile the reduce operation into an atomic add, just do it. If you know enough to compile it into an atomic add, you also know that atomic add is commutative.

WH: If you have something more complex, assume it's associative but don't assume it's commutative. It significantly limits the applicability of the algorithms.

NM: I’ll do some more measurements and come back with data.

MM: When the elemental function is commutative, in that case, use whatever technique you want to preserve associativity

YK: You may want to allow people to say that

WH: I want to see, in practice, if that makes a difference

TS: What's a non-trivial example of a noncommutative reduce operator?

MM: Matrix multiplication is associative and non-commutative

RH: (continuing)

Spec Wording

reducePar and scanPar use values from the original O array and results pusged onto an A array

"repeat in an arbitary and implementation dependent order len-1 times." "select 2 previously unselected indices, k1 and k2 from O and A"

WH: What is the result of reducePar when the input is an empty array?

Agreement to follow the same empty array behaviour currently defined by Array.prototype.reduce

Why Parallel Versions

Sufficiently sophisticated copiler argument

... need slide.

What we have learned

Pressure on Memory Management Latency

(just wait for slides)

MM: Earlier said whitelisting things known to be immutable or threadsafe?

RH: No, have to define "thread safe"

NM: have not done that, want to replay executions without side effects

Next Steps

(copy slides)


LH: There was other work that Brendan had shown, re: SIMD. Is that still for ES7?

NM: (recapping current progress, no answer for ES7)

Mixed discussion about comprehensions, the introduction of .buildPar, filterPar, reducePar, mapPar

TS: As we added parallel versions of map, reduce, etc. needed parallel of comprehesions which is buildPar

MM/JH: (substantial use of comprehensions in other languages)

WH: Desire to have a parallel comprehension syntax.

?: Why not just optimize the current comprehension syntax?

WH: For exactly the same reason why we're discussing parallel map et al instead of reusing map: it's hard in general to tell whether calls to functions can be reordered.

LH: (subjectively) the comprehension form is more attractive

Signature of Array.from map callback

(Allen Wirfs-Brock)

AWB: Currently differs in callback arguments:


callback.call(thisValue, v)


callback.call(thisValue, v, i, source);

RW: The change is supported in Map.prototype.forEach, Set.prototype.forEach, where the last argument is the set or map

AWB: But what can you actually do with that source object if it is just an iterator object?

JH: What

AWB: Consider scenario where someone might want to use the same map callback function for old-style map callback functions + Array.from

AWB: Functions that try to index into an iterator (3rd param) would get undefined, because its an iterator -- not an array

RW: There's a 3rd case for index, eg. tracking index for conditional execution (eg. even/odd element). Might concede the 3rd argument

AWB: Map.prototype.forEach() passes key (for "index" param). Set.prototype.forEach() passes element

AWB: Obscuring errors if arguments don't match expectations

RW: This is a user-code problem

JH: Could we leave it out and require a free variable?

RW: Would be weird that the Array mappers don't leave out the 3rd argument

RH: We find the index very valuable for picking up stuff from free vars

RW: Let's provide index/key for both paths, but not the 3rd param. If you need that you can use a closed over free-var


Bug 1571 RegExp Syntax


AWB: ES5 changed (?=) and (?!) from zero-width atoms to assertions

LH: If web reality matches 1571

MB, WH: Roll the change back to ES3, all browsers match ES3 behaviour

AWB: Need to update the ES6 web reality

DC: Did this make it into the bug suites?

LH: Must not have, because no major browser is failing.

WH: How much does test262 test detection of syntax errors?

BT: A lot but probably not enough


Change “EscapeSequence 0 [lookahead ∉ DecimalDigit]” to match reality


AWB: Strict mode explicitly disallows octal escapes.

MB: Technically \08 isn't an octal escape sequence though since 8 is not an octal digit; not sure if the strict mode rule applies

LH: We should take this offline

WH: Not a DecimalIntegerLiteral, which can only have one digit if it starts with a zero.

?: So '\08' is a null followed by '8'.

WH: No, it's not that either. The grammar has a lookahead restriction that states that a decimal integer escape cannot be followed by a digit. It's a syntax error.


Implementation Dependencies in String.prototype.replace

AWB: "Table 40 — Replacement Text Symbol Substitutions": someone should research what implementations do here (any differences or “web reality” to match?)

This issue dates back to ES3


RegExp toString escaping not fully specified

AWB: may need a more explicit spec.

WH: This was intentional when we defined toString in ES3. If the RegExp is constructed from a string, the string is not always usable as-is due to issues such as //, ///, and others. Evolution of regexps to support non-BMP unicode may introduce other cases due to the cover grammar.

WH: Given that the source string is not usable as-is, there is no obvious unique value that toString ought to return. An implementation might choose to optimize or simplify regexp patterns (example: replace /[zzzzz][.]\u0041/ with /z.A/), and implementations may differ in how far they go in such optimizations. In ES3 we decided to specify the behavior of the returned string: if eval'd, it must produce an identically behaving RegExp. Don't see anything that would invalidate that decision since then.

MB: Browsers currently re-use the exact pattern, e.g. String(/a/) vs. String(/\x61/) – normalization/serialization would be welcome

RW: ES3 spec says "...src may or may not be identical to the source property...." when referring to whether RegExp.prototype.toString() should return the same pattern given to it ...This language disappears in ES5

MB: eval( RegExp(string) ) may not result as intended e.g. if string is '/' or ''.

WH: specifying toString completely is a can of worms; instead we should add a requirement that leaves the exact toString behavior up to the implementation, as long as eval( RegExp(string)) returns a regular expression that has identical behavior.

?: Not all browsers correctly implement the rule that RegExp toString results must be evalable into the same regular expression.

WH: That would be a browser bug.

AWB: Some browsers haven't been paying close attention to this.

WH: Best fixable by putting a few test cases in test262.


Allen's TODO Summary

BT: Can you describe the "MOP/Proxy property enumeration API" item?

AWB: There are outstanding enumeration issues that we need to finally address.

Introduction and Language Overview


LH: Is the recent work you've done on scope complete?

AWB: Still have work to do on eval scope

BT: That's whether or not there is an implied block

RW: This is not to say that literally the difference is the addition of "{" + source + "}", but that you could reason about the result in such a way

AWB/LH: Approximately.

...re: Modules

JM: Can work to help Dave extract Module knowledge

RW: Review, find missing parts, report it (bugs, to Dave, etc)

AWB: HTML comments syntax should be specified for Annex B https://bugs.ecmascript.org/show_bug.cgi?id=2610

ES7 Process, New Proposal Home


AWB/BT/LH/RW: mixed discussion and agreement to replace the wiki.


RW: Should this github repo contain actual proposal info?

BT: Haven't decided yet, but seems reasonable

RW: Will hold off until the organizational story is complete.

RW: We should have a guideline on format for linked proposals (see http://wiki.ecmascript.org/doku.php?id=strawman:string_padding as a possible example)

Discussion about what topics should be in this guideline

BT: (to YK) send a PR with your proposal proposal.

JN: Please review the review sign up sheet and sign up.

4.4 Object.getOwnPropertyDescriptors

(Rick Waldron)

RW: this is the analog of defineProperties This is for ES7.

MM: Returns array or iterator?

RW: It returns a plain object that can be passed directly to defineOwnProperties

MM: Does it inherit from Object.prototype?

RW: Uknown. Open issue.

WH: What if you have a proxy that represents a massively infinite structure, what does this do?

RW: Unknown. Open issue. No reason to rush, this is an ES7 thing.

AWB: Must be same answer as what you get from getOwnPropertyNames

RW: Makes sense.

DC: Returns things that are not enumerable?

RW: Yes.

MM: I have no problem with this. What about symbol properties?

AWB: Open issue.

MM: This one is a trivial polyfill.

AWB: Any library can implement this. They should experiment and figure out what's useful.

YK: There are many issues. Would be best for us to decide what the right behavior is.

AWB: If you have a complex object you don't necessarily want to create all these property descriptors... Lots of allocations that get thrown out immediately. May not be a good idea.

YK: Maybe you want a fn with a callback that yields in the value

AWB: Or something like iterator but it doesn't necessarily fit.

MM: There might already be a polyfill in the Traits.js library.

WH: Why does it return an object instead of matching the behavior of Reflect.ownKeys?

RW: To pass to O.dPs

BN: Why no 'own' in the name even though they make own properties.

AWB: History - you can imagine dealing with own properties and inherited properties, you have to make a choice about which you deal with. Methods explicitly have own in it. In situations where the only thing you could deal with drop the 'own'. Defining implies own.

BN: Descriptors is so verbose... why?

RW: You get back a descriptor. There is already a getOwnPropertyDescriptor.

ACHIEVEMENT UNLOCKED: Longer API name than getOwnPropertyDescriptor!


4.5 Array.prototype.contains

(Rick Waldron)

RW: ES5 adds String.prototype.contains. Seems oversight that we don't have the same thing in Array. But, we can wait until ES7.

BT: Any spec text?

RW: Not yet, just mailing list discussions.

WH: Are you searching for elements or subsequences? If goal is to be analogous with string you would be searching for subsequences.

DC: We didn't do that for indexOf... Rick suggests continuing in that tradition.

WH: That's confusing. If it's not analogous, it should have a different name...

MB: Would be nice for DOM (would get rid of abstractions). DOM has contains for classList.

YK: Why not use has like set?

MB: Because classList already uses contains.

BT: Is this different than indexOf?

RW: Open question.


4.6 Updates to parseInt

(Rick Waldron)

RW: Should parseInt handle new octal and binary integer literal syntax? bug #1585

WH: Which octal syntax? 0123 or 0o123?

RW: 0[OoBb] only.

AWB: Essentially add the new literal syntax to parseInt.

WH: Sounds great, love to do it. But are there security problems? For example, let's say you have a website that parses the same 0o123 integer twice, one time uses parseInt, other time uses something else that isn't aware of the new prefixes and thinks that parseInt would return 0. Validation might pass but actual value would be wrong.

RW: Doesn't this exist with hex integer literals?

WH: No, hex literal has been around since the beginnning... These would be new. It's a breaking change.

MM: What is the rule that you propose to recognize an octal literal?

RW: Those in the spec: 0b/0B or 0O/0o.

LH: This works today (returns 0). This is a breaking change...

AWB: Applications may not want this behavior...

MB: You can use Number("0b11") or Number("0o42") instead, at least in V8. (ToNumber in the spec should be updated to make this official: https://bugs.ecmascript.org/show_bug.cgi?id=1584)

LH: Was that a breaking change? Looks like, but we went from NaN to actually returning a number.

WH: It's a breaking change. parseInt looks for a valid prefix and ignores the rest. parseInt('0o123') currently returns 0 because it sees the starting 0.


It's dead. RW to close the bug wontfix.

4.3, Update Object.assign to accept multiple sources

(Rick Waldron)

RW: Object.assign is useful. Multiple real-world APIs do this, but most allow multiple sources.

AWB: Some have additional options (enumerable vs. non-enumerable, shallow vs. deep copy).

RW: We selected an appropriate name (assign) that set it apart from existing APIs (ie. extend, or merge). We got consensus on this. Problem is that the response from practitioners has been negative. They want a multiple sources version.

EF: Didn't we solve that with reduce?

RW: Somewhat, but it introduces a bug.

RW: I tend to agree it falls short of the cowpath. We should fix for ES6.

YK: one of the common use cases for assign where you're supporting multiple mixins

BT: Why is name important?

AWB: Anyone else who has defined Object.<that name> could clobber existing stuff.

SM: Want an immutable version?

RW: Workaround - just use first source as empty object.

AWB: We considered that in the future we might want to add an options record. We weren't trying to provide an end-user solution but a primitive.

EF: If we only had support for one source and target and people used the reduce pattern we could break the web in the future if we want to extend this later.

RW: It will be a WTF that we ignored the cowpath.

AWB: That's why we chose a different name. This isn't extends.

YK: It's about real use cases.

WH: Why do the existing methods ignore exceptions?

MM: If some props cause exceptions and others don't, rather than have it be random which prop took, you have a gaurantee that all non-exceptional properties took. Do same thing with DP.

BT: What options?

AWB: Filter function, whether symbols are used. :: Discussion about whether and what was discussed previously, confirmed prevous consensus was target and source previously, but we didn't explicitly say multiple sources was out ::

YK: We decided that we were going to do assign now, and punt on more complex APIs for ES7. We don't need copying APIs for very specific use cases.

RW: this is a super common use case.

AWB: Most common is single source + target

YK: People will want multiple sources and won't see it as different API.

AWB: Concern that for people who are doing mixins, this is the wrong primitive thing.

YK: Won't happen. Doesn't rebind super. So we need ES7 to handle super correctly.

BE: Who's against?

AWB: I'm not enthusiastic. Won't stand in the way.

BE: Seems strictly winning to have multiple arguments.


5.1 Object.entries, Object.values

(Rick Waldron)

RW: ES5 added Object.keys. For ES7, Object.entries and Object.values make sense. These return arrays.

BT: Array of arrays for entries?

RW: Yes. You can pass to Map constructor.

YK: Important to be iterable.

AWB: Why not return iterator?

RW: Agree it's crappy but it makes sense because keys returns array.

AWB: Alternatively we could add this to a standard Dict module.

BT: Assuming we get standard modules?

AWB: We'll get them.


Test 262 Update

BT: A lot of pull requests piling up ... Domenic will port promise tests ... Awaiting the contributor agreement form

BN: Will contribute Generator tests

BT: Also need syntax tests

DL: V8 is beginning to implement ES6 and will want to contribute back the tests

RW: We'll need to update the current PRs with any guidelines

MM: For tests that are not specifically specified as strict-only or sloppy-only, currently the test262 harness only tests these in sloppy mode. Must test these in both strict and sloppy by default.

BT: Issues with the error message string varying across platforms

BT: Also need cross realm association testing ...Naively, we could write in-browser tests, but ideally we want host-agnostic testing.

AWB: Need to stay up to date with reviewing

BT: Rick and I have been doing this

DL: V8 team can assist as well

BT: Will need to support a variety of disparate test systems

MB: What about Annex B tests? They’d have to run in a browser; test runner needs to support that somehow.

MM: Detect Annex B features, then if they’re present, test if they behave as per the spec, if not, fail silently.

BT: Continue to report test coverage gaps.


Async Functions Question

(Jafar Husain)

JH: Question about the omission of the close() method from iterator

BE: close came from Python, was on generator objects. We unified send and next, we didn't include close.

JH: To be specific, I want the object returned by @@iterator to include a close() method.

BE: The problem with close in python is that it leaks GC semantics.

JH: I understand this isn't based on IEnumerator, but think there is a important case being missed.

MM: I like this addition

BE: we solved by making close automatic

DL: If you have close, and have try/finally there is no guarantee that the close is called.

BE: In a browser, to avoid denial of service, finally is not guaranteed to run.

AWB: Iterator prototocol doesn't require implementing throw, so that the iterator must only implement next

BE: Andy Wingo presented cases for removal https://mail.mozilla.org/pipermail/es-discuss/2013-May/030683.html

Discussion about whether this is a breaking change, resolution - it is but probably not a big deal

The name "return" is more accurate then "close"

LH: We need a write up that explains why this is critical

RW: (to JH) confirm a write up for tomorrow

Discussion about "reserving" names on iterator objects.

BE: A symbol for the name of the method?

The risk is not big enough

JH: ES6 for-of won't look for a return() method, but ES7 for-of will look for it and invoke.

BE: Deeper issue, we had close, but we got rid of it. Was it because no one used it as presented, or was because Andy's points were sufficiently convincing.

YK: Having close() exist cause hazards?

BE: No

BN: You might break the for-of to exhaust the iterator elsewhere.

MM: Under this proposal, when the for-of exits early (break) it would cause the generator to take the exit path. If we do this, we have to do this in ES6. It's sufficiently weird enough that I'm not convinced.

YK: You'd opt in?

LH/MM: no

MM: If the for-of exits early, the return() on the generator is called

This must be done in ES6, if done at all.

JH: Similar to Object.unobserve, sometimes you want to stop doing something that you've started.

Discussion about ways around and reasons for use.

MM: What if we modify: no explicit close/return on exit of for-of. generator objects have this method, but must be explicitly called.

JH: That allows for a future syntactic form?

MM: Probably wouldn't add syntactic form.

LH: Worried about the whole notion of having a return mechanism on generator objects (referring to the example given by Andy Wingo, item 2, surprising yield behaviour).

JH: If for-of doesn't explicitly call the return()?

BE: That's addressed by item 3 in Andy's concerns

MM: You could still do this by writing out manually

JH: Yes

BE: Recap: no explicit for-of semantics, has a return() that can be called if needed?

BN: may want return() to exit without triggering catch, vs. throw()

MM: Please present use cases that illustrate

JH: Confirmed.


(continued to April 10, 2014)