Re: Generator Arrow Functions
On 27 Nov 2013, at 3:29 , Brendan Eich bren...@mozilla.com wrote: [...] also some future-hostility to function! wanting =! (remember ! is a unary prefix operator). Other spellings all have ASI or other future-hostility woes. What is `function!` ? Or will that be explained in the meeting notes, too? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
It is one proposed syntax for async functions. On Nov 27, 2013 6:20 AM, Axel Rauschmayer a...@rauschma.de wrote: On 27 Nov 2013, at 3:29 , Brendan Eich bren...@mozilla.com wrote: [...] also some future-hostility to function! wanting =! (remember ! is a unary prefix operator). Other spellings all have ASI or other future-hostility woes. What is `function!` ? Or will that be explained in the meeting notes, too? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Extensible typed arrays use case in the wild
I found this relevant to some previous discussions: https://github.com/feross/native-buffer-browserify/commit/18c6784277e25db01ee145e5dfaaf23bb5b311fc The native-buffer-browserify is an attempt to provide a typed array-based version of Node.js's Buffer interface [1]. (Buffer is something that was created before TypedArrays existed.) In Firefox, which has non-extensible typed arrays, this cannot be done, and so the author had to resort to using a proxy that forwards to the underlying typed array. In other engines, it worked straightforwardly. I believe this use case could also be solved by ES6-style subclassing support on TypedArrays, but that doesn't appear to work in Firefox either, from my tests. [1]: http://nodejs.org/docs/latest/api/buffer.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible typed arrays use case in the wild
Hey Domenic, thanks for bringing this up. IIUC, extensible typed arrays have been decided on, so we will implement them. CCing Niko, who is working on typed arrays and typed objects. On Wed, Nov 27, 2013 at 2:56 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I found this relevant to some previous discussions: https://github.com/feross/native-buffer-browserify/commit/18c6784277e25db01ee145e5dfaaf23bb5b311fc The native-buffer-browserify is an attempt to provide a typed array-based version of Node.js's Buffer interface [1]. (Buffer is something that was created before TypedArrays existed.) In Firefox, which has non-extensible typed arrays, this cannot be done, and so the author had to resort to using a proxy that forwards to the underlying typed array. In other engines, it worked straightforwardly. I believe this use case could also be solved by ES6-style subclassing support on TypedArrays, but that doesn't appear to work in Firefox either, from my tests. [1]: http://nodejs.org/docs/latest/api/buffer.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
November 20, 2013 Meeting Notes
# Nov 20 Meeting Notes
John Neumann (JN), Allen Wirfs-Brock (AWB), Yehuda Katz (YK), Eric
Ferraiuolo (EF), Erik Arvidsson (EA), Rick Hudson (RH), Matt Sweeney (MS),
Rick Waldron (RW), Dmitry Soshnikov (DS), Sebastian Markbage (SM), Ben
Newman (BN), Reid Burke (RB), Waldemar Horwat (WH), Doug Crockford (DC),
Tom Van Custem (TVC), Mark Miller (MM), Brian Terlson (BT), Andreas
Rossberg (ARB), Alex Russell (AR)
## Report from the Ecma Secretariat (CC Report)
(Istvan Sebestyen)
### Status of the TC39 RFTG
January 2014 Meeting deadline
## 4.2 Clarification of the interaction of unicode escapes and
identification syntax
(Waldemar Horwat)
WH: In ES3 we added the ability to use unicode escape sequences in
Identifiers, ie.
```js
var f\u1234o = 17;
```
The restriction was that the unicode escape sequence still had to be a
valid identifier. ES3 and ES5 never allowed unicode escapes to substitute
non-user-data characters of other tokens such as reserved words or
punctuation.
the contention is that ES6 has an incompatible lexical grammar change that
lets you write things like:
```js
\u0069f(x===15)
// if(x===15)
There also was a bit confusion about whether escape sequences can occur in
regexp flags, even though the grammar never allowed them there either:
/abc/\u...
// unicode for the flags
```
AWB: Things that came up in ES5:
- can you declare a variable that has the same unicode escape sequence as a
keyword?
```js
var f\u0
```
- introduced in ES5:
```js
// allow
foo.for()
```
ie. Identifier vs IdentifierName
WH: Cannot use escapes to create identifiers that would be invalid. Also
opposed to allowing escapes inside keywords; there should be just one
spelling of the keyword ```if```, and it should not include ```\u0069f```.
So what should we do about \u0069f(x===15) ? It depends on how we interpret
the ES3/ES5 rule that states that escapes cannot be used to create
identifiernames that don't conform to the identifiername grammar.
Option A: Treat the if there as an identifier because there are some
contexts in which if can be used as an identifier (notably after a dot),
making this into a function call.
Option B: The if there cannot be an identifier in this context, so it's a
syntax error because we're trying to spell a reserved word with an escape.
AWB: Agree there is ambiguity
MM: https://code.google.com/p/google-caja/wiki/SecurityAdvisory20131121
Handling of unicode escapes in identifiers can lead to security issues
Records the vulnerability that has now been fixed in Caja at the price of
additional pre-processing. This vulnerability which was caused by ambiguity
in interpretations of the ES5 spec by different browser makers.
STH: If there are systems that need to search code for specific forms
MM: It would be harmful to code that looked at keywords, then this could
circumvent those assumptions.
AWB/WH: (recapping acceptable use of reserved words as identifiernames)
BE: We can fix it, but it's just not how ES6 spec works
WH: If it is a ReservedWord, it may not be spelled with an escape.
MM: This solves Sam's static code case
BE: No escape processing upstream?
WH: (agreeing)
AWB: We can specify in the grammar that where we write if it means that
exact character sequence
...Anywhere we express literal keywords, we mean those character sequences.
Consensus/Resolution
- ReservedWords, including contextual, can only be spelled with ascii
characters, ie. the literal character sequence.
- No escapes allowed in such ReservedWords
## Performance impact of Tail Calls
(Brian Terlson)
BT: Wondering if any implementors have begun work on these? Are there
considerations for existing code that will become tail call?
YK/AWB: Any examples?
BT: Stack frame manipulation
BE: It's not a zero work to new work, it's an old work to different work.
STH: There's a lot of work on this subject, presumably tail calls should be
able to run as fast as it does currently. No advice that's implementation
independent.
ARB: Standard techniques should be applicable. Foresee a lot of work.
YK: The only real value for practioners is for compile-to-js cases.
DC: This is actually the most exciting feature for me, because it allows
BE: Will have someone work on this for SpiderMonkey
RW: Agree that implementors will feel the pressure once practioners
experience the benefits that Doug describes.
DH: Allows for real cps transformations that won't blow the stack and don't
require awful setTimeout hacks. FP idioms being available to JS.
Consensus/Resolution
- Share implementation experience
## super and object literals
(Allen Wirfs-Brock)
(needs slides)
AWB: Issue: how do you mixin some methods that reference super?
```js
Object.mixin(obj, ???);
```
In the process of mixing, Object.mixin will rebind super references to the
target. The big problem: `super` is currently explicitly illegal within an
object literal:
```js
Object.mixin(obj, {
toString() {
return
November 19, 2013 Meeting Notes
# Nov 19 Meeting Notes John Neumann (JN), Allen Wirfs-Brock (AWB), Yehuda Katz (YK), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Rick Hudson (RH), Matt Sweeney (MS), Rafael Weinstein (RWS), Alex Russell (AR), Rick Waldron (RW), Dmitry Soshnikov (DS), Jeff Morrison (JM), Sebastian Markbage (SM), Ben Newman (BN), Reid Burke (RB), Waldemar Horwat (WH), Doug Crockford (DC), Tom Van Custem (TVC), Mark Miller (MM) ## Welcome JN: (Introductions) DC: (Logistics) JN: ...updating status of RFTG ...Adopt agenda? Unanimous approval JN: Approval of Sept Minutes? Unanimous approval ## ES6 Status AWB: (presenting Luke's spreadsheet with remaining features that need attention) https://skydrive.live.com/view.aspx?resid=704A682DC00D8AAD!59602app=Excelauthkey=!AAMixsO0TuyPYwc ...Function.prototype.toString still needs attention BE: Mark is to write spec, in this case under-specify AWB: - Refutable pattern matching is deferred - still need specification for enumerate / getOwnPropertyKeys/Symbols in various places - Proxy handlers, cut - C-style for-let BE: We agreed on semantics AWB: We agreed on outer capture, but won't try to update per iteration. Need per iteration binding. YK: This is the consensus I recall AWB: - Modules, static semantics complete - No loader/runtime semantics yet. - Dave will have a complete spec this meeting YK: (confirms that it's complete) AWB: Yes, but not yet in the spec. - Standard Modules deferred. (TVC dials in) ## 4.4 Finalizing the Proxy API for ES6 (Presented by Tom Van Cutsem) TVC: First three relate to es-discuss threads, re: simplifying Proxy. Jason Orendorff expressed concerns. - hasOwn() - invoke() WH: AWB: Looked for traps for call BE: Total traps? AWB: Now 14 traps. BE: Cool. Not including hasOwn()? AWB: Not including TVC: The next is `invoke()` trap. Leave out for now to avoid inconsistencies with `get()`? YK: How do you implement virtual objects? ie. an object whose `this` object is always the proxy. Can't do it reliably without invoke. WH: Still not reliable, even with invoke. YK: So what are the cases? AWB: Can still implement a virtual object or full membrane, or thin wrapper. YK: Not the use case. Want to make an object where `this` is the proxy and not the target. TVC: Are you arguing that `this` should remain bound to the proxy object upon forwarding? If yes, this is the default. YK: As long as maintaining equivalence between `foo.bar()` and `bar.call(foo)` AWB: yes. TVC: Regarding Handler API: not enough motivating use cases for proxy handlers without community use. Propose to defer. AWB: Let's publish the library code TVC: It's already on github, as part of my shim. I will publish it as a separate project to make it more accessible. TVC: `Proxy` as a constructor? Currently, no `new` throws TypeError AWB: Not really a class AR: You create new ones? AWB: No prototype AR: Gives an instance, why not new AWB: Would need an @@create YK: Then shouldn't be capitalized BE: We can do proxy AWB: (to Tom) the concern is: if it's not new-able, should it be little-p proxy? TVC: Given choice between little-p proxy and requiring `new`, I prefer `new` RW: Agree with Alex, `new Proxy()` creates new Proxies, so allow `new` AR: Let's not duck the charge on @@create. WH: Proxy is not a class. YK: ...But has allocation WH: I would hate to specify what happens when subclassing from Proxy AWB: Must create a special constructor TVC: @@create doesn't make sense here BE: Is Proxy a class? (General: no) TVC: DS: What is typeof and instanceof AWB/BE: object BE: Capital P AWB: Ca??? DS: Whatever Proxy creates? BE: That depends on what is created. DS: By default? BE: typeof depends if there is a call trap. instanceof depends on the prototype chain. All in the spec, so can create any object (apart from private state issues) AWB: Ok, into the future... would value objects allow `new`? BE: (int64 example) ...back to why should `new` throw on Proxy constructor. BE: Seems counter intuitive: Proxy constructs objects. `int64` creates a value. callables construct objects [ inaudible ] BE: these are object constructor functions, which is what people want to do with new AWB: this is somewhere in the middle between newing a class and a random function that returns an object BE: in either case, it returns a new object and proxies are factories for object AWB: yeah, I agree...spec currently calls them proxy factory functions BE: pretty weird not to have new on this.. feels natural YK: Intuitively, the difference between returning an object and not a value AWB: we can do it...need to make it an exotic object with a special [[Construct]] AR: agree. Making it exotic is good. TVC: what's the summary? AWB: we allow new, we do it by making it exotic. EA: Do we REQUIRE new? WH: what does Map do without `new`? EA: Throws BE: Why are we requiring `new` again? RW: Needed for subclassing AWB: my objection is that we're trying to tell a
Re: November 19, 2013 Meeting Notes
Le 27/11/2013 19:14, Rick Waldron a écrit : # Nov 19 Meeting Notes ## 4.4 Finalizing the Proxy API for ES6 (Presented by Tom Van Cutsem) (...) DS: What is typeof and instanceof AWB/BE: object BE: Capital P AWB: Ca??? DS: Whatever Proxy creates? BE: That depends on what is created. DS: By default? BE: typeof depends if there is a call trap. instanceof depends on the prototype chain. All in the spec, so can create any object (apart from private state issues) Shouldn't it depend on the target's typeof value? depending on apply (not call) trap makes typeof unstable (delete handler.apply). In any case, extra caution is required to keep typeof stability for revokable proxies (on revocation, maybe the value need to be saved somewhere) nit: instanceof depends on the prototype chain = Note that it calls the getPrototypeOf trap which doesn't enforce anything for extensible objects [1], so *the* prototype chain has a more volatile meaning for proxies than it has for regular objects. David [1] https://mail.mozilla.org/pipermail/es-discuss/2013-September/033370.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proxies and bind (Was: November 20, 2013 Meeting Notes)
I wasn't there on day 2 so I may be lacking context, but I'd like to
clarify some parts in the notes re. proxies and Function.prototype.bind:
2013/11/27 Rick Waldron waldron.r...@gmail.com
EA: What happens when do bind on a function proxy?
MM: fail?
DH: This is shocking.
MM: bind is a perfect example, there is no conflict between security and
transparency. You'd like bind to work on proxy functions
Not sure why Mark mentioned that bind fails on function proxies. It doesn’t:
js var o = {}
js var p = new Proxy(function() { return this; }, {})
js var f = p.bind(o)
js f() === o
true
(and this works regardless of whether you use p.bind(o) or
Function.prototype.bind.call(p,o))
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: November 19, 2013 Meeting Notes
2013/11/27 David Bruant bruan...@gmail.com Le 27/11/2013 19:14, Rick Waldron a écrit : BE: typeof depends if there is a call trap. instanceof depends on the prototype chain. All in the spec, so can create any object (apart from private state issues) Shouldn't it depend on the target's typeof value? depending on apply (not call) trap makes typeof unstable (delete handler.apply). In any case, extra caution is required to keep typeof stability for revokable proxies (on revocation, maybe the value need to be saved somewhere) No, the current ES6 draft I believe gets it right: - typeof proxy does not depend on the presence of an apply trap, but on whether the target object has a [[Call]] internal method. So deleting handler.apply has no effect on the typeof value of the proxy. (see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typeof-operator-runtime-semantics-evaluation ) (the current draft does lose the ability for a proxy to transparently retain a non-standard typeof value. AFAICT, typeof proxy will always either return object or function) - a proxy whose target has a [[Call]] internal method will itself have a [[Call]] internal method. If the target does not have a [[Call]] internal method, then neither does the proxy (see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxycreate) - revoking a revocable proxy does not change whether or not it has a [[Call]] trap (see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-revocation-functions), so the typeof result will remain stable even when the proxy is revoked. nit: instanceof depends on the prototype chain = Note that it calls the getPrototypeOf trap which doesn't enforce anything for extensible objects [1], so *the* prototype chain has a more volatile meaning for proxies than it has for regular objects. Indeed, but only for proxies that claim to be extensible. For non-extensible proxies, the prototype chain is well-defined. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: November 19, 2013 Meeting Notes
Thanks, Tom -- your whole bulleted list looks good, but in particular:
Tom Van Cutsem wrote:
(the current draft does lose the ability for a proxy to transparently
retain a non-standard typeof value. AFAICT, typeof proxy will always
either return object or function)
This seems right. Any typeof extension will come from value objects
('value class' -- still need time to write it up, possibly this coming
week).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: November 20, 2013 Meeting Notes
On Wed, Nov 27, 2013 at 10:15 AM, Rick Waldron waldron.r...@gmail.comwrote:
# Nov 20 Meeting Notes
Consensus/Resolution
- Remove Object.mixin
- toMethod() wins -- debate about argument order
Function.prototype.toMethod(home[, mname])
A small observation: the toMethod is cool, and Allen recently showed an
example of how it can be applied:
```
(function(){super()})() //throws because unbound super
(function(){super()}).toMethod(Array.prototype,toString).call([])///ok
```
The only thing I'm worried (and that Mark mentioned), is that the
super-inheritance is tightly related to the class-based sugar. While the
approach above again exposes the prototypes implementation detail via this
`.prototype` stuff.
Probably should be two:
```
.toMethod(Array, 'toString'); // to (instance/proto) method
.toStaticMethod(Array, 'toString'); // constructor's method
``
The former, as mentioned, works with the `.prototype` not exposing this
detail to the user-level code.
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: November 20, 2013 Meeting Notes
On Wed, Nov 27, 2013 at 5:49 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: .toMethod(Array, 'toString'); // to (instance/proto) method That does not seem like the lowest level of primitive since now there is no way to no pass an ordinary object as the [[HomeObject]]. Now I have to introduce a temporary object that has a prototype property on it. This is low level API and I don't think it is worth doing a property get for the prototype here. .toStaticMethod(Array, 'toString'); // constructor's method In this case .toMethod(Array, 'toString') is what you want (given that you are making a static method for a sub class of Array) -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
Will you also be citing ECMA-404 normatively to avoid this sort of divergence in the future? On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray tb...@textuality.com wrote: To do this, I think the draft requires these changes: - Remove the trailing section of section 1.2, starting with “ECMAscript 5.1 enumerates...” [because the difference no longer exists] - In section 2: -- remove “A JSON text is a serialized object or array.” -- Insert: “A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. Implementations which generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.” -- Change the JSON-text production to read: JSON-text = value On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) mamil...@cisco.com wrote: There appears to be consensus to change JSON-text to allow for any JSON value -- not just object / array -- while noting that object or array as the top-level is the most interoperable. We will ask the Document Editor to make this change to draft-ietf-json-rfc4627bis. - Paul Hoffman and Matt Miller ___ json mailing list j...@ietf.org https://www.ietf.org/mailman/listinfo/json ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: November 20, 2013 Meeting Notes
On Wed, Nov 27, 2013 at 4:53 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: On Wed, Nov 27, 2013 at 5:49 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: .toMethod(Array, 'toString'); // to (instance/proto) method That does not seem like the lowest level of primitive since now there is no way to no pass an ordinary object as the [[HomeObject]]. Now I have to introduce a temporary object that has a prototype property on it. Yeah, potentially it could check for `isConstructor()`, otherwise get the home directly. This is low level API and I don't think it is worth doing a property get for the prototype here. But if you say this is a really low level API, and won't be often used by user-level / application-level code, then I think it's fine. .toStaticMethod(Array, 'toString'); // constructor's method In this case .toMethod(Array, 'toString') is what you want (given that you are making a static method for a sub class of Array) Yeah. Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
