4 June 2014 TC39 Meeting Notes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

4 June 2014 TC39 Meeting Notes

Ben Newman
# June 4 2014 Meeting Notes  

Brian Terleson (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), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK), Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich (BE), Mark Miller (MM), Peter Jensen (PJ)


## Adoption of the agenda


AWB: Adding section 8: Other ES6 Technical Issues
AWB: Adding "Report from ECMA secretariat" to HTML integration section

SK: Add an agenda item to discuss JSDoc and its use in editors

AWB: add "ArrayBuffer neutering" to ES6 agenda items


## Conclusion/Resolution

- Agenda Approved
- Minutes from April 2014 approved


## Scheduling of TC39 meeting


JN: Meeting schedule changes are problematic 

- In november, we'll select for next year.
- The current meeting dates need to be approved now and committed to

YK: Didn't weigh scheduling concerns of champions vs. non-champions well

AWB: Hard to weigh those concerns until we know what will be talked about

Next: 

- 29-31 July 2014 at Microsoft in Redmond, WA (USA) 
- 23-25 September 2014 at Bocoup in Boston, MA (USA) 
- 18-20 November 2014 at PayPal in San Jose, CA (USA)


AWB: Should set agendas based on schedule, rather than other way around

JN: I will propose meeting dates in September for your consideration


## Agenda for this meeting

DH: Talk about generators tomorrow (Thursday), to accommodate Brendan Eich and potentially Andy Wingo

## 4.2 Schedule Review

AWB: Goal was to present ES6 to ECMA general assembly for approval later this year, meaning we need to approve finished draft at September meeting, meaning we need a finished draft at July meeting. I don't see any way we can have even an approximately finished draft by July. Also starting to get good implementer feedback which is causing spec churn, but there are pieces missing review. If we ratified what we have now we'd be missing serious implementation feedback.
AWB: Propose we slip our publication target by 6 months. Spec will still be feature frozen. We're just fixing bugs and accepting implementer feedback.
Concern 1: is this opening the door to feature creep? Important it doesn't do that.
Concern 2: Will this simply delay implementer work by 6 months?
Concern 3: Perception of committee failure?

DH: We should move forward on the work and message that we're doing so. Spec is not what drives the work, spec is the final capture of a stable consensus. I'm OK with the spec slipping.

WH: Don't want to repeat E4X (ECMAScript-for-XML) experience of shipping buggy spec, and later abandoning it.

?: Hazy distinction between calling something a bug vs. a revisited conclusion.

WH: The issues with E4X were clearly bugs.

AWB: This committee can tell the difference between fixing bugs and revisiting conclusions.

AWB: Focus energy on ES7 [if you want to revisit conclusions]!

AWB: Other factor playing into spec review is test262, to which we've just gotten approval to accept contributions

JN: Can we approve the change of dates (presenting finished draft to TC39 committee in November rather than July)?

AWB: Everything we want to include is in the spec at some level of quality, it's just a matter of ensuring quality.

YK: If you're an implementer, you shouldn't treat this as a slippage.

AWB: Should we start naming spec editions using years rather than an incrementing number (ES2015 vs. ES6)?

AWB: Let's not throw this in with messaging about the schedule postponement.

YK: The fact that people are used to ES5/ES6/etc. will make the change important as a messaging technique.

BE: Let's sleep on it.

## Conclusion/Resolution

- Postponement of presentation of final ES6 draft agreed upon
- Switch to yearly naming convention to be slept on


## Update on changes to spec since last meeting


AWB: Object.prototype.toString.call(proxy) will be either [object Object] or [object Function] depending on whether the proxy is callable, so that there is no way to tell that an object is a Proxy
MM: Have to choose between use cases, and being able to hide Proxy-ness is the better choice
AWB: Already considered/dropped isProxy, so using O.p.toString as a back-door would have been inconsistent with that decision

AWB: Another Proxy issue MM and I talked about: custom property descriptor attributes on Proxies, specifically adding additional attributes to the descriptor that the Proxy could recognize.

```js
Object.defineProperty(obj, propName, {
  value: whatever,
  customAttribute: attrValue
});

// Should the customAttribute be preserved here?
Object.getOwnPropertyDescriptor(obj, propName).customAttribute
```

MM: Decision was to disallow/ignore custom attributes. Might add an additional object metadata API in future versions of the language, but it will be separate from property descriptors.

AWB: for (let x in x) -- "bombs" because referring to x before temporal dead zone ends.

```js
let o;
for (let x in (o={ f(){ return x }, x=42 }) {
    o[x](); // gives TDZ error
}
```

MM: In for(;;) {} loop, can say for(let x = expr;...) -- that expression iterates the zeroth item of x?

DH: Yes

## Conclusion/Resolution 
- Leave as is currently spec'd


## 4.3 `arguments` and `caller` poisoning & static class methods of same name

BT: Should we keep doing the poisoning?

MM: We poison to make stack-walking code fail noisily, early

AWB: In the long run, is more confusion likely to reside in not being able to have static methods called "arguments" or "caller," or not being able to get away with stack walking?

YK: Having strict mode code dynamically allow static methods named "caller" and "arguments" when non-strict mode code forbids them seems strange for strict mode (which usually only forbids things).

BT: If we can't get rid of arguments and caller can we make the properties configurable?

MM: I no longer object to making .caller and .arguments configurable, so that you can make static methods with those names.

## Conclusion/Resolution:
- Make the .caller and .arguments configurable properties for all functions (except sloppy mode functions), so that they can be overwritten.


## 4.4 `return` on generator/iterator types

## Conclusion/Resolution

- Postpone until tomorrow morning at ~10:30, after Istvan's talk at 10:15.


## 4.6 Reserving additional words (`yield`, `async`, and `await` in particular)

YK: Want to support async functions in top-level scripts.

AWB: Is a module with no imports essentially a top-level script?

AWB: We've gotten away with introducing new contextual keywords without reserving them.

MM: Seems useful for code that uses `async` in an arguably legal context [e.g., as a variable name] to be able to continue doing so.

YK: There's a cost to something being legal in a top-level script but not legal in a module.

MM: `yield` and `await` are already reserved (i.e. can't be variable names) in generators and async functions, respectively

DH: think about async modules as an argument in favor of reserving `await` at the top level of modules

BE: strict mode already reserves `yield` and `async`

MM: And modules are strict!

## Conclusion/Resolution

- Reserve only `await` as a keyword in modules.
- `async` and `module` work as contextual keywords because of their position (which can't conflict with variable names).
- `yield` is reserved in strict mode, so doesn't need additional reservation.


## 4.7 Removal of Realms API from ES6 (postponement to ES7)

MM: No serious draft implementations of Realms API, even by implementors who have implemented module loaders.

MM: And it's the most security-sensitive part of the module loading spec.

MM: Can we have modules and module loaders without Realms?

DH: Yes, when I proposed I mentioned that modules can come without Realms if necessary.

DH: Let me state my point: I don't want to slow down Realms being implemented, and I worry if we remove them from the spec implementors won't have anything to go on when implementing modules or experimenting with Realms

AWB: Can we defer to July after Dave and I have had enough time to work through modules.

DH: I do want us to get them right, but I don't want to see it continually kicked down the road

AR: Want to be able to use Realms to specify (and build polyfills for) e.g. same-origin <iframe>s.

MM: We want to explain the existing behavior of same-origin <iframe>s in terms of Realms, and we can't do that until we specify the Realm API

MM: Don't defer specification until ES7 now, but let implementors start implementing the Realms API, and if we end up deferring it, no one will be surprised.

DH: Talk to Domenic about spear-heading a polyfill?

YK: Not as much interest in Realms in the Node.js community.

DH: Polyfill hard to do for the parts of the API that are the most interesting.

AR: Hixie and/or Anne VK (or Boris Z) specify these kinds of things for the HTML spec, so maybe we should have a small meeting with them.

## Conclusion/Resolution

- Postpone decision to defer Realms to ES7 until next meeting.
- This does NOT amount to postponing to ES7!
- Bear in mind that it is separable from module loading, so we can still go either way (ES6 or ES7).


## 4.8 ArrayBuffer neutering

AWB: What did we decide this morning? (MM wasn't here then)

DH: Planning to have a discussion with implementors to decide what makes the most sense (throwing an exception on property access, or making .length be 0)

MM: Feel strongly there should be an isNeutered test operation, so you don't have to use a try-catch to test neuteredness (if we go with the exception throwing behavior)

WH: Why should the length return 0 instead of throwing on a neutered object?

DH: Lets you have a fast case in element lookup that checks for a 0 length.

WH: That doesn't answer the question. You can internally have a 0 length on neutered objects for fast lookup but throw if someone calls the length method.

DH: Let's think about using a different metaphor/terminology that isn't vaguely sexual (i.e. something other than "neutered")

MM: Not just the API (e.g. isNeutered) but also the spec language

DH: Probably not super-high demand for isNeutered because you usually know that you've used up an array and thrown it away. Code that needs to check for neuteredness (because the object might not have been neutered) is probably broken/confused/unlikely.

BE: Should isNeutered be a static method on Reflect or an instance method on ArrayBuffer?

DH: ArrayBuffer instance method

AWB: Is this feature-creep, though?

## Conclusion/Resolution

- Don't add isNeutered yet, and expect clients use try-catch when accessing properties to determine status.
- Also remember to change the name. "Released"? "Vacated"?


## 6 Test-262 Status

BT: Have the CLA as a PDF document, now need to tell everyone with pull requests to go to the website, download the PDF, sign it, and send it to us.

AWB: How can we streamline that process?

BT: Continuing to have that conversation with Istvan and Norbert.

AWB: Where do contributors send the CLA?

BT: That could be clearer.

BT: Now have support for Promises in the test harness, but it's not clear how to keep promises 

BN: Couldn't the test harness call promise.done(...)?

YK: That's doable, as is having the test harness check whether the promise is resolved or rejected.

EA: Traceur uses standard mocha/chai/tdd testing library.

BT: Willing to give up purity in the tests for the sake of coverage (overlap between test suites is fine, e.g. if both Traceur and Regenerator contribute their test suites).

AWB: Should we have a notion of a test suite rating, indicating whether they are "spec-level" or less formal than that.

BT: Don't want to discourage people from submitting less formal tests.

MM: Are we running tests that should succeed in both strict and sloppy modes in both modes?

BT: I'll open an issue on https://github.com/tc39/test262 for that.

EA: Tests don't closely follow the spec, and don't tend to be written as test262 tests from the start, just because it's easier.

JM: Not clear how to run tests against new implementations.

YK: Transpiler projects (Traceur, esnext) should make an effort to make this easier.

BT: How did test suite review work for ES5?

AWB: I did a lot of it when I was at Microsoft.

MM: Want to do commit-then-review for tests.

BT: Yes, because then it's easier to weed out tests because (correct) implementations fail them.
 
MM: Who would sign up to write tests for a chapter of the spec?

AWB: Brian should create twitter.com/testecmascript to evangelize the testing message.

BT: Need to reflect the depth of coverage as well as breadth, and that's hard to capture in a list.

JM: People love progress bars, gamification?

BN: What language features can be used in tests?

BT: Philosophy is to use only ES5 outside the specific ES6 features under test.

## Conclusion/Resolution

- No spec decisions to be made here, just a status report.


## Object.observe status

Want a way to express narrower interest via the listening API (for performance) rather than filtering in the callback, e.g. listening for changes to just one property, rather than all changes to the object.

DH: Is the `Object.observe` protocol extensible enough to support Map and Set modifications?

YK: `Object.observe` is meant to work out of the box for data property mutations, but you can also emit a synthetic change record for object types like Map and Set

## Conclusion/Resolution

- YK to draft proposal for changes to the spec and present it to champions.


## IO Streams


AR: Domenic's streams repository represents a consensus among a relatively large number of people, and a small minority outside of that favors the Rx style [Observables?].

DH: Re: asynchronous iteration, we've laid the groundwork for an iteration protocol that can be both synchronous and asynchronous. Expect async/await to be very popular, building on Promises.

DH: We have single-valued synchronous functions (normal functions), multi-valued synchronous functions (generators), single-valued async functions (async/await), but no multi-valued async functions. JH thinking about this in terms of Observables, from a C# perspective/precedent.

AWB: Re: error types and detection, IO APIs tend to have web platform dependencies, like DOMError/DOMException, which we can't invoke in the ES7(?) spec.

YK: Difficult to reliably subclass ES Errors in general, regardless of whether developers will pay attention to Error type distinctions.

MM: `class MyError extends Error {}` gives a distinct new error type, right?

AWB: Have to do it right [e.g. invoke super() in constructor to record stack trace?], but not impossible.

MM: Wasn't there a proposal to introduce typed catch clauses?

BE: catch guards were implemented in SpiderMonkey a long time ago.

YK: That would help with reporting errors to the user.

BE: Really?
BE: Termination-style exception handling won out over resumption-style a long time ago, and that was probably a failure.

BE, YK, MM: Discussion about whether rejected Promises support interpreting exceptions contextually in a way that allows helpful errors to be reported to the user.

MM: Example: IndexOutOfBounds exception can bubble up from calls to a lower-level table access abstraction, but be caught by the client of a higher-level table access abstraction, and the only thing the client can conclude is that her input parameter was out of bounds, when that isn't necessarily true or helpful.

BE: requestAutocomplete example: how to Promise-ify the response (as recommended by Domenic: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254143.html )? Do you need distinct Error types in order to respond differently to different kinds of rejection?

MM: That distinction wouldn't tell you which stage of a .then chain produced the error, necessarily, unless you were careful about encoding that information in the value of the Error.

BE: DOMException vs. other exception types doesn't seem like a helpful distinction.

AWB: Should we try to replace WebIDL? (fourth bullet point from the gist above)

DH: Browser implementors love WebIDL, so anything that replaces it has to be as convenient as that. YK's idea: the new interface description language would prepend Legacy to existing WebIDL types, but still support them.

MM: What about a design language that compiles to WebIDL?

DH: Problem: people explicitly argue against better interface design because it's not convenient/expressible in WebIDL.

MM: Right, the path of least resistance in WebIDL is not good JavaScript.

DH, AR: TypeScript seemed like a way to define signatures of APIs, but was solving a different problem.

DH: Need a way to express what kind of implicit conversions are applied to passed-in values (something that TypeScript doesn't have).

YK: Also want to be able to express APIs in terms of function/method overloading (different behaviors for different input types), which is more like TypeScript than WebIDL.

AWB: If no work happens to build a better IDL, we'll be stuck with the status quo.

YK: Want to be able to describe `Promise<T>` result types as such, rather than `{ then: ???, catch: ??? }`

SK: Willing to start working on a new IDL design, with help.

DH: Want to capture duality between Array.isArray arrays and array-like objects, and instanceof-Promise objects vs. { then: Function } objects.

SK: Can we improve whatever was lacking about TypeScript?

AR, YK: TypeScript types don't mean quite what you think they mean (Number, String).

AR: Union types not supportable in TS today, so you can't express some important overloadings.

## Conclusion/Resolution
- As JN points out, we really have to get in contact with the W3C folks and make sure they're sympathetic, and we also really have to commit meaningfully to working on a new IDL, neither of which seems like something this committee can decide unilaterally.
- Worth exploring, but no commitment at this date.


## Web APIs that could move to ES(7+)


MM: URL and fetch() together sort of imply that HTTP (vs html/dom/etc) is moving from browser into the lang -- and that's...

MM: Because http is being used in non-browsers, that's interesting

DH: Node isn't waiting on APIs for TC39 (it does a lot of its own things)

DH: Receptive to idea to shift some of these into "the lang", but unclear who to work with on some of these

BE: When you say "the lang", you mean separate spec

*agreement*

BE: If self-hosted, how much does it need to be anything more than code on GitHub

YK: Engines can do opts that can't be done in userland

## Conclusion/Resolution

- General openness to moving these APIs into ES7+, but no firm commitment yet on any single item.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 4 June 2014 TC39 Meeting Notes

Ben Newman
Expanded Conclusion/Resolution for the ArrayBuffer neutering discussion:

## Conclusion/Resolution

- Don't add isNeutered yet, and expect clients use try-catch when accessing properties to determine status.
- Also remember to change the name. "Released"? "Vacated"?
- Any attempt to access (read or write) binary data elements of an ArrayBuffer that has been "neutered" will throw a TypeError exception.
- Accessing the byteLength property of an ArrayBuffer that has been "neutered" will throw TypeError exception. 
- Have not yet decided what happens to the the "length", "byteOffset", and "byteLength"  properties of a TypedArray whose underlying ArrayBuffer gets neutered.
- Keep the behavior that out of bounds reads of a TypedArray (whose buffer has not been neutered) returns undefined (MM: or throws, in strict mode) and that out of bounds write are no-ops (MM: throws in strict mode).

TC39 recognizes that the above are breaking changes relative to the  Khronos spec. but we believe that the behavior of silently treating neutered buffers as 0-length buffers is seriously flawed and would set a terrible precedent for any future "transferable" data types.

Ben

His errors are volitional and are the portals of discovery.
-- James Joyce


On Wed, Jun 11, 2014 at 9:08 AM, Ben Newman <[hidden email]> wrote:
# June 4 2014 Meeting Notes  

Brian Terleson (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), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK), Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich (BE), Mark Miller (MM), Peter Jensen (PJ)


## Adoption of the agenda


AWB: Adding section 8: Other ES6 Technical Issues
AWB: Adding "Report from ECMA secretariat" to HTML integration section

SK: Add an agenda item to discuss JSDoc and its use in editors

AWB: add "ArrayBuffer neutering" to ES6 agenda items


## Conclusion/Resolution

- Agenda Approved
- Minutes from April 2014 approved


## Scheduling of TC39 meeting


JN: Meeting schedule changes are problematic 

- In november, we'll select for next year.
- The current meeting dates need to be approved now and committed to

YK: Didn't weigh scheduling concerns of champions vs. non-champions well

AWB: Hard to weigh those concerns until we know what will be talked about

Next: 

- 29-31 July 2014 at Microsoft in Redmond, WA (USA) 
- 23-25 September 2014 at Bocoup in Boston, MA (USA) 
- 18-20 November 2014 at PayPal in San Jose, CA (USA)


AWB: Should set agendas based on schedule, rather than other way around

JN: I will propose meeting dates in September for your consideration


## Agenda for this meeting

DH: Talk about generators tomorrow (Thursday), to accommodate Brendan Eich and potentially Andy Wingo

## 4.2 Schedule Review

AWB: Goal was to present ES6 to ECMA general assembly for approval later this year, meaning we need to approve finished draft at September meeting, meaning we need a finished draft at July meeting. I don't see any way we can have even an approximately finished draft by July. Also starting to get good implementer feedback which is causing spec churn, but there are pieces missing review. If we ratified what we have now we'd be missing serious implementation feedback.
AWB: Propose we slip our publication target by 6 months. Spec will still be feature frozen. We're just fixing bugs and accepting implementer feedback.
Concern 1: is this opening the door to feature creep? Important it doesn't do that.
Concern 2: Will this simply delay implementer work by 6 months?
Concern 3: Perception of committee failure?

DH: We should move forward on the work and message that we're doing so. Spec is not what drives the work, spec is the final capture of a stable consensus. I'm OK with the spec slipping.

WH: Don't want to repeat E4X (ECMAScript-for-XML) experience of shipping buggy spec, and later abandoning it.

?: Hazy distinction between calling something a bug vs. a revisited conclusion.

WH: The issues with E4X were clearly bugs.

AWB: This committee can tell the difference between fixing bugs and revisiting conclusions.

AWB: Focus energy on ES7 [if you want to revisit conclusions]!

AWB: Other factor playing into spec review is test262, to which we've just gotten approval to accept contributions

JN: Can we approve the change of dates (presenting finished draft to TC39 committee in November rather than July)?

AWB: Everything we want to include is in the spec at some level of quality, it's just a matter of ensuring quality.

YK: If you're an implementer, you shouldn't treat this as a slippage.

AWB: Should we start naming spec editions using years rather than an incrementing number (ES2015 vs. ES6)?

AWB: Let's not throw this in with messaging about the schedule postponement.

YK: The fact that people are used to ES5/ES6/etc. will make the change important as a messaging technique.

BE: Let's sleep on it.

## Conclusion/Resolution

- Postponement of presentation of final ES6 draft agreed upon
- Switch to yearly naming convention to be slept on


## Update on changes to spec since last meeting


AWB: Object.prototype.toString.call(proxy) will be either [object Object] or [object Function] depending on whether the proxy is callable, so that there is no way to tell that an object is a Proxy
MM: Have to choose between use cases, and being able to hide Proxy-ness is the better choice
AWB: Already considered/dropped isProxy, so using O.p.toString as a back-door would have been inconsistent with that decision

AWB: Another Proxy issue MM and I talked about: custom property descriptor attributes on Proxies, specifically adding additional attributes to the descriptor that the Proxy could recognize.

```js
Object.defineProperty(obj, propName, {
  value: whatever,
  customAttribute: attrValue
});

// Should the customAttribute be preserved here?
Object.getOwnPropertyDescriptor(obj, propName).customAttribute
```

MM: Decision was to disallow/ignore custom attributes. Might add an additional object metadata API in future versions of the language, but it will be separate from property descriptors.

AWB: for (let x in x) -- "bombs" because referring to x before temporal dead zone ends.

```js
let o;
for (let x in (o={ f(){ return x }, x=42 }) {
    o[x](); // gives TDZ error
}
```

MM: In for(;;) {} loop, can say for(let x = expr;...) -- that expression iterates the zeroth item of x?

DH: Yes

## Conclusion/Resolution 
- Leave as is currently spec'd


## 4.3 `arguments` and `caller` poisoning & static class methods of same name

BT: Should we keep doing the poisoning?

MM: We poison to make stack-walking code fail noisily, early

AWB: In the long run, is more confusion likely to reside in not being able to have static methods called "arguments" or "caller," or not being able to get away with stack walking?

YK: Having strict mode code dynamically allow static methods named "caller" and "arguments" when non-strict mode code forbids them seems strange for strict mode (which usually only forbids things).

BT: If we can't get rid of arguments and caller can we make the properties configurable?

MM: I no longer object to making .caller and .arguments configurable, so that you can make static methods with those names.

## Conclusion/Resolution:
- Make the .caller and .arguments configurable properties for all functions (except sloppy mode functions), so that they can be overwritten.


## 4.4 `return` on generator/iterator types

## Conclusion/Resolution

- Postpone until tomorrow morning at ~10:30, after Istvan's talk at 10:15.


## 4.6 Reserving additional words (`yield`, `async`, and `await` in particular)

YK: Want to support async functions in top-level scripts.

AWB: Is a module with no imports essentially a top-level script?

AWB: We've gotten away with introducing new contextual keywords without reserving them.

MM: Seems useful for code that uses `async` in an arguably legal context [e.g., as a variable name] to be able to continue doing so.

YK: There's a cost to something being legal in a top-level script but not legal in a module.

MM: `yield` and `await` are already reserved (i.e. can't be variable names) in generators and async functions, respectively

DH: think about async modules as an argument in favor of reserving `await` at the top level of modules

BE: strict mode already reserves `yield` and `async`

MM: And modules are strict!

## Conclusion/Resolution

- Reserve only `await` as a keyword in modules.
- `async` and `module` work as contextual keywords because of their position (which can't conflict with variable names).
- `yield` is reserved in strict mode, so doesn't need additional reservation.


## 4.7 Removal of Realms API from ES6 (postponement to ES7)

MM: No serious draft implementations of Realms API, even by implementors who have implemented module loaders.

MM: And it's the most security-sensitive part of the module loading spec.

MM: Can we have modules and module loaders without Realms?

DH: Yes, when I proposed I mentioned that modules can come without Realms if necessary.

DH: Let me state my point: I don't want to slow down Realms being implemented, and I worry if we remove them from the spec implementors won't have anything to go on when implementing modules or experimenting with Realms

AWB: Can we defer to July after Dave and I have had enough time to work through modules.

DH: I do want us to get them right, but I don't want to see it continually kicked down the road

AR: Want to be able to use Realms to specify (and build polyfills for) e.g. same-origin <iframe>s.

MM: We want to explain the existing behavior of same-origin <iframe>s in terms of Realms, and we can't do that until we specify the Realm API

MM: Don't defer specification until ES7 now, but let implementors start implementing the Realms API, and if we end up deferring it, no one will be surprised.

DH: Talk to Domenic about spear-heading a polyfill?

YK: Not as much interest in Realms in the Node.js community.

DH: Polyfill hard to do for the parts of the API that are the most interesting.

AR: Hixie and/or Anne VK (or Boris Z) specify these kinds of things for the HTML spec, so maybe we should have a small meeting with them.

## Conclusion/Resolution

- Postpone decision to defer Realms to ES7 until next meeting.
- This does NOT amount to postponing to ES7!
- Bear in mind that it is separable from module loading, so we can still go either way (ES6 or ES7).


## 4.8 ArrayBuffer neutering

AWB: What did we decide this morning? (MM wasn't here then)

DH: Planning to have a discussion with implementors to decide what makes the most sense (throwing an exception on property access, or making .length be 0)

MM: Feel strongly there should be an isNeutered test operation, so you don't have to use a try-catch to test neuteredness (if we go with the exception throwing behavior)

WH: Why should the length return 0 instead of throwing on a neutered object?

DH: Lets you have a fast case in element lookup that checks for a 0 length.

WH: That doesn't answer the question. You can internally have a 0 length on neutered objects for fast lookup but throw if someone calls the length method.

DH: Let's think about using a different metaphor/terminology that isn't vaguely sexual (i.e. something other than "neutered")

MM: Not just the API (e.g. isNeutered) but also the spec language

DH: Probably not super-high demand for isNeutered because you usually know that you've used up an array and thrown it away. Code that needs to check for neuteredness (because the object might not have been neutered) is probably broken/confused/unlikely.

BE: Should isNeutered be a static method on Reflect or an instance method on ArrayBuffer?

DH: ArrayBuffer instance method

AWB: Is this feature-creep, though?

## Conclusion/Resolution

- Don't add isNeutered yet, and expect clients use try-catch when accessing properties to determine status.
- Also remember to change the name. "Released"? "Vacated"?


## 6 Test-262 Status

BT: Have the CLA as a PDF document, now need to tell everyone with pull requests to go to the website, download the PDF, sign it, and send it to us.

AWB: How can we streamline that process?

BT: Continuing to have that conversation with Istvan and Norbert.

AWB: Where do contributors send the CLA?

BT: That could be clearer.

BT: Now have support for Promises in the test harness, but it's not clear how to keep promises 

BN: Couldn't the test harness call promise.done(...)?

YK: That's doable, as is having the test harness check whether the promise is resolved or rejected.

EA: Traceur uses standard mocha/chai/tdd testing library.

BT: Willing to give up purity in the tests for the sake of coverage (overlap between test suites is fine, e.g. if both Traceur and Regenerator contribute their test suites).

AWB: Should we have a notion of a test suite rating, indicating whether they are "spec-level" or less formal than that.

BT: Don't want to discourage people from submitting less formal tests.

MM: Are we running tests that should succeed in both strict and sloppy modes in both modes?

BT: I'll open an issue on https://github.com/tc39/test262 for that.

EA: Tests don't closely follow the spec, and don't tend to be written as test262 tests from the start, just because it's easier.

JM: Not clear how to run tests against new implementations.

YK: Transpiler projects (Traceur, esnext) should make an effort to make this easier.

BT: How did test suite review work for ES5?

AWB: I did a lot of it when I was at Microsoft.

MM: Want to do commit-then-review for tests.

BT: Yes, because then it's easier to weed out tests because (correct) implementations fail them.
 
MM: Who would sign up to write tests for a chapter of the spec?

AWB: Brian should create twitter.com/testecmascript to evangelize the testing message.

BT: Need to reflect the depth of coverage as well as breadth, and that's hard to capture in a list.

JM: People love progress bars, gamification?

BN: What language features can be used in tests?

BT: Philosophy is to use only ES5 outside the specific ES6 features under test.

## Conclusion/Resolution

- No spec decisions to be made here, just a status report.


## Object.observe status

Want a way to express narrower interest via the listening API (for performance) rather than filtering in the callback, e.g. listening for changes to just one property, rather than all changes to the object.

DH: Is the `Object.observe` protocol extensible enough to support Map and Set modifications?

YK: `Object.observe` is meant to work out of the box for data property mutations, but you can also emit a synthetic change record for object types like Map and Set

## Conclusion/Resolution

- YK to draft proposal for changes to the spec and present it to champions.


## IO Streams


AR: Domenic's streams repository represents a consensus among a relatively large number of people, and a small minority outside of that favors the Rx style [Observables?].

DH: Re: asynchronous iteration, we've laid the groundwork for an iteration protocol that can be both synchronous and asynchronous. Expect async/await to be very popular, building on Promises.

DH: We have single-valued synchronous functions (normal functions), multi-valued synchronous functions (generators), single-valued async functions (async/await), but no multi-valued async functions. JH thinking about this in terms of Observables, from a C# perspective/precedent.

AWB: Re: error types and detection, IO APIs tend to have web platform dependencies, like DOMError/DOMException, which we can't invoke in the ES7(?) spec.

YK: Difficult to reliably subclass ES Errors in general, regardless of whether developers will pay attention to Error type distinctions.

MM: `class MyError extends Error {}` gives a distinct new error type, right?

AWB: Have to do it right [e.g. invoke super() in constructor to record stack trace?], but not impossible.

MM: Wasn't there a proposal to introduce typed catch clauses?

BE: catch guards were implemented in SpiderMonkey a long time ago.

YK: That would help with reporting errors to the user.

BE: Really?
BE: Termination-style exception handling won out over resumption-style a long time ago, and that was probably a failure.

BE, YK, MM: Discussion about whether rejected Promises support interpreting exceptions contextually in a way that allows helpful errors to be reported to the user.

MM: Example: IndexOutOfBounds exception can bubble up from calls to a lower-level table access abstraction, but be caught by the client of a higher-level table access abstraction, and the only thing the client can conclude is that her input parameter was out of bounds, when that isn't necessarily true or helpful.

BE: requestAutocomplete example: how to Promise-ify the response (as recommended by Domenic: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254143.html )? Do you need distinct Error types in order to respond differently to different kinds of rejection?

MM: That distinction wouldn't tell you which stage of a .then chain produced the error, necessarily, unless you were careful about encoding that information in the value of the Error.

BE: DOMException vs. other exception types doesn't seem like a helpful distinction.

AWB: Should we try to replace WebIDL? (fourth bullet point from the gist above)

DH: Browser implementors love WebIDL, so anything that replaces it has to be as convenient as that. YK's idea: the new interface description language would prepend Legacy to existing WebIDL types, but still support them.

MM: What about a design language that compiles to WebIDL?

DH: Problem: people explicitly argue against better interface design because it's not convenient/expressible in WebIDL.

MM: Right, the path of least resistance in WebIDL is not good JavaScript.

DH, AR: TypeScript seemed like a way to define signatures of APIs, but was solving a different problem.

DH: Need a way to express what kind of implicit conversions are applied to passed-in values (something that TypeScript doesn't have).

YK: Also want to be able to express APIs in terms of function/method overloading (different behaviors for different input types), which is more like TypeScript than WebIDL.

AWB: If no work happens to build a better IDL, we'll be stuck with the status quo.

YK: Want to be able to describe `Promise<T>` result types as such, rather than `{ then: ???, catch: ??? }`

SK: Willing to start working on a new IDL design, with help.

DH: Want to capture duality between Array.isArray arrays and array-like objects, and instanceof-Promise objects vs. { then: Function } objects.

SK: Can we improve whatever was lacking about TypeScript?

AR, YK: TypeScript types don't mean quite what you think they mean (Number, String).

AR: Union types not supportable in TS today, so you can't express some important overloadings.

## Conclusion/Resolution
- As JN points out, we really have to get in contact with the W3C folks and make sure they're sympathetic, and we also really have to commit meaningfully to working on a new IDL, neither of which seems like something this committee can decide unilaterally.
- Worth exploring, but no commitment at this date.


## Web APIs that could move to ES(7+)


MM: URL and fetch() together sort of imply that HTTP (vs html/dom/etc) is moving from browser into the lang -- and that's...

MM: Because http is being used in non-browsers, that's interesting

DH: Node isn't waiting on APIs for TC39 (it does a lot of its own things)

DH: Receptive to idea to shift some of these into "the lang", but unclear who to work with on some of these

BE: When you say "the lang", you mean separate spec

*agreement*

BE: If self-hosted, how much does it need to be anything more than code on GitHub

YK: Engines can do opts that can't be done in userland

## Conclusion/Resolution

- General openness to moving these APIs into ES7+, but no firm commitment yet on any single item.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 4 June 2014 TC39 Meeting Notes

David Bruant-5
In reply to this post by Ben Newman
Le 11/06/2014 18:08, Ben Newman a écrit :
> https://gist.github.com/annevk/3db3fbda2b95e5ae9427
>
> AWB: Should we try to replace WebIDL? (fourth bullet point from the
> gist above)
For what purpose? Replacing WebIDL isn't an end in itself.
Who would be the target of this replacement? Spec writers (TC39 or
W3C)?  authors? Implementors? All of these together?

> DH: Browser implementors love WebIDL, so anything that replaces it has
> to be as convenient as that. YK's idea: the new interface description
> language would prepend Legacy to existing WebIDL types, but still
> support them
+1.

> MM: What about a design language that compiles to WebIDL?
>
> DH: Problem: people explicitly argue against better interface design
> because it's not convenient/expressible in WebIDL.
>
> MM: Right, the path of least resistance in WebIDL is not good JavaScript.
Why? (I'm not saying I disagree, but I'm trying to understand what
WebIDL lacks)
What are people opinions on the path of least resistance in describing
interfaces in TypeScript?

> DH, AR: TypeScript seemed like a way to define signatures of APIs, but
> was solving a different problem.
>
> DH: Need a way to express what kind of implicit conversions are
> applied to passed-in values (something that TypeScript doesn't have).
As far as developers are concerned, it doesn't seem like an issue, so it
looks like the TypeScript interface language is sufficiently expressive
for most developer needs.
However, it looks like the notion of "interface" for standard features
changes whether it's taken from the point of view of an implementor or
an author.
Implementors have an imperative of interoperability with legacy APIs
which is a constraint authors don't have.

> YK: Also want to be able to express APIs in terms of function/method
> overloading (different behaviors for different input types), which is
> more like TypeScript than WebIDL.
>
> AWB: If no work happens to build a better IDL, we'll be stuck with the
> status quo.
>
> YK: Want to be able to describe `Promise<T>` result types as such,
> rather than `{ then: ???, catch: ??? }`
I want to agree, but IIRC thenables are considered like promises by
built-in algorithms, so apparently, the consensus is not that people
want a `Promise<T>` type as such separate from {then, catch?}.

> SK: Willing to start working on a new IDL design, with help.
>
> DH: Want to capture duality between Array.isArray arrays and
> array-like objects, and instanceof-Promise objects vs. { then:
> Function } objects.
>
> SK: Can we improve whatever was lacking about TypeScript?
An annotation system like there is now in WebIDL might be enough an
addition to express legacy behaviors.

> AR, YK: TypeScript types don't mean quite what you think they mean
> (Number, String).
A new interface language could keep the TypeScript syntax and adapt the
semantics as felt appropriate.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 4 June 2014 TC39 Meeting Notes

Boris Zbarsky
On 6/12/14, 4:53 AM, David Bruant wrote:
>> DH: Problem: people explicitly argue against better interface design
>> because it's not convenient/expressible in WebIDL.

To the extent that it's the latter, we should fix WebIDL.

To the extent that it's people just being lazy, that's just not acceptable.

Obviously we should try to make the path of least resistance be good
interface design; WebIDL aimed at that from the start.  It doesn't help
that the concept of "good interface design" is not universally agreed on
and not time-invariant....

So with that in mind, we want something that will allow us to express
existing DOM APIs (which are by and large not "good interface design" in
various ways), something that allows us to express whatever people
actually want to express (and we better come to some agreement about
what that is), and a way to transition from the current WebIDL to the
new thing with minimal pain in some way, both in terms of rewriting all
the existing specs that use WebIDL and browser implementations that do.

This all would have been way easier 3-4 years ago when WebIDL was first
being put together.  :(

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss