Last weeks meeting notes
On Aug 3, 2009, at 10:21 AM, Erik Arvidsson wrote:
Discussing whether we want to put setTimeout etc into ECMAScript? There is a clearly a gap between ES and HTML5. How can we close the gap? Execution model needs to be standardized.
See current WHATWG work:
www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-windowtimers-settimeout
Brendan:
set setMissing
setIndexed getIndexed
Mark: ES4 had List/Vector. Brendan: Maciej also wanted Set
set covers the use case. It requires more work than setMissing (setIndexed/getIndexed) but it might be better to start simple.
Brendan:
a = [] a[(1 << 32) - 2] = 42; a[(1 << 32)] = 43; print(a[0]) => undefined a.length => (1 << 32) -1
To clarify this a bit (my whiteboard needs narration) the discussion
was about the trade-offs between a richer catchalls proposal that
specializes hooks for indexed properties, vs. one that has setMissing
and set -- or only set (called on every set). The simpler the
proposal, the harder to optimize: an implementation might have to take
apart the catchall set handler to see whether it is checking for an
"index" identifier, e.g. Such simplification of the catchalls proposal
would slow down non-indexed-property catchalls too.
I recall favoring at least a split between set and setMissing, as
David-Sarah had suggested based on the wiki'ed catchalls proposal's
set/add separation:
None of this addresses the "climbing the meta ladder" observation/
objection from Waldemar. The mirages approach based on mirrors may --
Mark cited this paper:
prog.vub.ac.be/Publications/2007/vub-prog-tr-07-16.pdf
Brendan:
let o = {x: 0, y: 1} const;
Allen:
var o = { method f() {} };
it would do binding.
The punchline is to enhance object initialisers to express attributes
needed for static analysis and optimization, so these are more truly
"object literals", more like ML record type instances.
On Mon, 3 Aug 2009, Erik Arvidsson wrote:
Discussing whether we want to put setTimeout etc into ECMAScript? There is a clearly a gap between ES and HTML5. How can we close the gap? Execution model needs to be standardized.
I'd be happy to coordinate on this. As a warning, though, specifying this in a well-defined manner will require some manner of interaction with the event loop mechanism in HTML5 (or rather, in whatever environment the script is running in). I'm not sure exactly how this would work, but it shouldn't be too hard -- we probably just need to define some terms that the host environment's spec can hook into.
None of this addresses the "climbing the meta ladder" observation/ objection from Waldemar. The mirages approach based on mirrors may
-- Mark cited this paper:
In a nutshell: mirages mitigate some of the issues with meta-regress
by requiring the 'catch-all handler' to be attached to an object when
the object is defined. Think of a mirage as an object with a
statically-known catch-all handler. Hence, it is known at compile-time
whether or not an object's property access should be intercepted and
even which specific operations (has,get,set,invoke,...) are redefined.
Primitive actions performed on mirages can still run arbitrary code,
but the scope of the problem is restricted to mirages, not to
arbitrary objects.
While there are uses of catch-all handlers for which the static
binding of the handler is not an issue, for other use cases it
probably is. Statically binding the catch-all handler to an object
requires foresight on behalf of the creator of the object: it's not
possible to bind a catch-all handler to an object after it has been
created.
For those that would still be interested in reading the paper: it is
largely superseded by the following journal article: dx.doi.org/
10.1002/spe.909 (if you are interested in the full-text pdf, I can
send it to you)
Kind , Tom
Wednesday 2009-07-29
Istvan covers the minutes of the ECMA general assembly
Discussion about the license ECMA proposed. We need to make sure that derivative work is allowed. The TC should provide a derived disclaimer.
Mark, Brendan, others: open source principles important.
2000-4000 downloads per month for ES3 doc at ECMA (e4x is also popular)
Should we trademark ECMAScript? Yes, unless someone brings up reason not to. ECMA will do it.
AI: Istvan to register ECMAScript as a trademark.
Discussing whether we want to put setTimeout etc into ECMAScript? There is a clearly a gap between ES and HTML5. How can we close the gap? Execution model needs to be standardized.
Brendan: I want to focus on hot language issues first
Meet with W3C in September. We'll invite Phillipe (from w3c).
Open Issues:
Allen: I have no open issues. Last issue was with configurability with eval:ed vars. var - non configurable, eval var - configurable. [[Global]].foo is configurable (the standard behavior). Eval in function that creates vars are deletable (and were in ES1). Hopefully there are not other issues that are this serious lurking in the draft ;-)
Mark: xhr+eval is not the same as createElement('script')
Allen: Another issue that came up was the RegExp issue regarding idents. Applied David Sarah's fix.
Another issue that was fixed as an UTF-8 issue. Made it explicit. Would not decode invalid UTF-8.
Doug: Would that break existing implementations?
Allen: Depends on existing implementations but it should not.
Brendan: There is a regexp bug in IE and SpiderMonkey with turkish-i
"iI\u0131".replace(/[\u0131]/gi, "#") IE: "###" FF: "#I#" others: "iI#"
upper(i) =>I
upper(I) => I
upper(turkish-i) => turkish-i
B: What was the utf-8 resolution
A: throw an exception (URIError) if the decoded value is not valid utf-8
Doug: There was the language thing with strict code unit. We use "code unit" in the text where it should not be used since we should only use "code unit" in to Unicode.
A: The main work task is now to reformat the spec to match the ECMA style (typography etc)
A: We have to have the final document at the next meeting (Sept)
B: Is there anything we should double check? A: Chapter 10 is significant. All the array and string algorithms were rewritten. A: My sense: There must be bugs in this document. No worse than in ES3
Test suites:
Mark: Sputnik and MS ES5 tests test the specs. The moz tests tests mozilla implementation. Should reflect the spec and the structure of the spec Rob: Our concern is that the spec does not match the implementation. Mark: Sputnik tests extensions as well Rob: Mozilla is willing to contribute their tests. Rob: Doing development as an open source project with code reviews etc. Brendan: It doesn't matter where it is hosted Rob: At one point we hope to have enough tests to publish it as a technical report. The project is not an official ECMA project but a future report will be an ECMA branded report.
CodePlex should be fine. Mark to ask Christian what his objections are.
(more below on hg.ecmascript.org)
Implementation testing and break the web testing. Mark believes that Microsoft are coming to a closure on the implementation front. Allen, and others, have been using their prototype for weeks without noticing anything. That doesn't prove anything but it is something.
What can we do if we do find a compat issue?
John Neumann: We cannot change it after September. Which goes to fast track to ISO. 6 months. Comments can be made during that time. And we can do revisions which will use the same edition number.
At next meeting we will approve the spec.
Brendan, Rob: Mozilla still implementing, aim to be done before next meeting.
Istvan: 2 meetings. Sept (in the bay area, most likely Google), Nov (with w3c).
Mark: Wants to distinguish ES6 and Harmony. ES6 is the next concrete spec and Harmony is the general direction.
Doug: Don't call it ES6. Group agreement there
What are the goals for Harmony?
1-9. The ES3.1 9 goals are still applicable (on the wiki) 10. To provide syntactic conveniences for good abstraction patterns. 11. To provide syntactic conveniences for high integrity patterns. 12. To minimize the additional semantic state needed beyond that provided by ES5 13. Reference implementation? Testable spec.
These got moved and cleaned up. The agreed goals and means are available at
harmony:harmony, harmony:proposals, strawman:strawman
Cormac: Should an ESH implementation also run ES5? How do they interact? Mark: Suggests ESH runs ES5strict but not necessarily ES5 Mark: use strict puts you in harmony
Make sure the language remains approachable by casual scripters.
Discussion about int and other number types that are wanted by code generating
Allen: First and foremost it is a language for humans
const f() {} is syntactic sugar for frozen functions.
It would be good if the ES5 object model is good enough for ES3, ES5 and ESH
Cormac: Harmony spec needs to spec compat mode with ES5 and strict mode
opt in?
mark:
if (function() { "use strict"; return this; }()) { // < ES5 } else { // ES5 }
Allen: Possible time frames for harmony Doug: Gating thing would be implementation, feature wrangling. Testable implementation and test suites and the synchronize that with the ecma calendar Cormac: 2 which ends up being 3 Cormac: There is the whole issue of formalism Allen: We could probably identify some smaller sub problems. Milestone would be to create a reference implementation for ES5
starts with a strawman. then moves to proposals, then specification as a patch Doug: What language. He likes the work Allen has been doing and suggests ES5 as the implementation language. Cormac: Spec ES5 in ES5 (the English prose) Mark: We could say that the interpreter is written in the common subsets of ES5 strict and ES3.
Spec. Formalism Use ES3/5s "interpreter" based on Allen Wirf-Brock's work Rewrite ES5 spec using above (1) replace pseudo code with ES code (2) Reorg as appropriate (3) Parser/grammar? Use new "ES5" spec as baseline for Harmony spec
Work flow straw man - vague feature/functionality/sketch proposal - "complete" informal spec spec patch - formal spec (Tech Report) Integrated into Harmony spec
Brendan: We already have hg.ecmascript.org setup.
Mark suggested we host shared Ecma testsuite at hg.ecmascript.org. General agreement, need to confirm with Allen.
Catchalls
Brendan: We should really get feedback from V8 and Apple and other VM people. Mark: There is another approach to catchalls similar to how it is done in E Allen: Catchalls should be cachable. Catchalls on prototype needs extra care Erik: There is also index getter/setter
Brendan:
set setMissing
setIndexed getIndexed
Mark: ES4 had List/Vector. Brendan: Maciej also wanted Set
set covers the use case. It requires more work than setMissing (setIndexed/getIndexed) but it might be better to start simple.
Brendan:
a = [] a[(1 << 32) - 2] = 42; a[(1 << 32)] = 43; print(a[0]) => undefined
a.length => (1 << 32) -1
Return to label
Mark: Still useful even without lambdas. Cormac: What does it give us that exceptions cannot achieve Codify a pattern and make sure that no one catches the exception
Hashes/Map
Allen: hashCode. Sure it introduces another source of non determinism Mark wants hash tables Mark: It introduces a covert channel Ephemeron
weak pointer. has 2 methods. registerExecutor/registerObserver which gets notified when the pointer is null
ephemeron table can be used to assign unique ids to objects. Chasing our tail. Mark: The ephemeron table is local so if you don't have a reference to it you cannot get the id Mark: We can introduce a new primitive. A number generator that returns a unique number for object that it is passed in
Messages to null - No, it is too late
Mark: Can we add modules to strawman or proposal. Brendan: Yes, add to strawman first
ByteArray/Blob
Nitro has it Canvas wants clamping and rounding Maybe we need bit blit on a new value type Brendan: We need a storage type, not necessarily bitblt operator. Mark: Could byte array be written in the language? Brendan: Yes, with catchalls Mark: Then it is not introducing new semantic state? Allen's concern is that we add a specialized object. Mark: Blob implies immutable, buffer, array implies mutable Allen: Why bytes and not bits? Mark: With bits we get to the endian issue :-)
Math.random()
Rob: What about an improved random? Mark: What about crypto? Brendan: We (moz) are planning to use their crypto libraries for Math.random(). If we provide something else people will still use Math.random which would still have the potential issue. Doug: We still need a fast random generator. Sam and Brendan countered that CPUs are much faster than in 1995, but Doug could be right. Only way to tell is to try the experiment. Mark: From a security point the issue is that there is a shared state.
More Math functions? hypot? log10?
Mark: How about a standardized debugging API. Not as part of ECMAScript but something the TC might be interested in. Brendan: There is some work going on in the open web between V8, Spidermonkey and Nitro. It seems like this will happen.
Spread
Mark: We should also allow spread to be used in object literals to expand
let a = {a: 0} let b = {b: 1, ...a} // {b:1, a: 0} let c = {...a, b: 1} // {a: 0, b:1}
Array like objects should work. Use same logic as for apply to determine length
Mark: { x: x, y: y, ...stuff }
enumerable own properties
Allen: It is a different semantics with the same operator. Mark: Call it spread-map Allen: This is syntactic sugar to the object literal Brendan cited successor-ml.org/index.php?title=Functional_record_extension_and_row_capture at this point (know from ES4 destructuring proposal discussion).
Mark: Is the following syntactic sugar conflict free?
const { ... }
Answer: no, this is destructuring, can't mean frozen object.
Allen:
{[...], x: x, }
in ES4 {const x: ...}
Brendan:
let o = {x: 0, y: 1} const;
Allen:
var o = { method f() {} };
it would do binding.
SES
Mark and Doug came up with this list on an earlier occasion:
function objects are frozen function have name property frozen functions do not have prototypes object literals inherits from null % becomes the modulo operator remove ==, remove != remove semicolon insertions remove with changes to eval change the status to ps and ls What to do with |this|? Probably leave it as ES5 strict
class Observable() { const listeners = [];
public addListener(listener) { listeners.push(listener); }
public notify() { for (let i = 0; i < listeners.length; i++) { listenersi; } } }
if a listeners references this it gets access to the listeners
(1, listeners[i])(...) gets around it. apply etc also gets around it
Doug persuaded Mark that the |this| hazard here was tolerable, compared to removing |this| from SES.
Big picture conclusion was Doug reevaluating SES in light of agreement to make a statically verifiable obj-cap subset of Harmony be a goal.
Wednesday 2009-07-29 Istvan covers the minutes of the ECMA general assembly Discussion about the license ECMA proposed. We need to make sure that derivative work is allowed. The TC should provide a derived disclaimer. Mark, Brendan, others: open source principles important. 2000-4000 downloads per month for ES3 doc at ECMA (e4x is also popular) Should we trademark ECMAScript? Yes, unless someone brings up reason not to. ECMA will do it. AI: Istvan to register ECMAScript as a trademark. Discussing whether we want to put setTimeout etc into ECMAScript? There is a clearly a gap between ES and HTML5. How can we close the gap? Execution model needs to be standardized. Brendan: I want to focus on hot language issues first Meet with W3C in September. We'll invite Phillipe (from w3c). 1. Global object vs this 2. Execution model 3. setTimeout 4. Event handlers 5. Multiple globals Open Issues: Allen: I have no open issues. Last issue was with configurability with eval:ed vars. var - non configurable, eval var - configurable. [[Global]].foo is configurable (the standard behavior). Eval in function that creates vars are deletable (and were in ES1). Hopefully there are not other issues that are this serious lurking in the draft ;-) Mark: xhr+eval is not the same as createElement('script') Allen: Another issue that came up was the RegExp issue regarding idents. Applied David Sarah's fix. Another issue that was fixed as an UTF-8 issue. Made it explicit. Would not decode invalid UTF-8. Doug: Would that break existing implementations? Allen: Depends on existing implementations but it should not. Brendan: There is a regexp bug in IE and SpiderMonkey with turkish-i "iI\u0131".replace(/[\u0131]/gi, "#") IE: "###" FF: "#I#" others: "iI#" upper(i) =>I upper(I) => I upper(turkish-i) => turkish-i B: What was the utf-8 resolution A: throw an exception (URIError) if the decoded value is not valid utf-8 Doug: There was the language thing with strict code unit. We use "code unit" in the text where it should not be used since we should only use "code unit" in regards to Unicode. A: The main work task is now to reformat the spec to match the ECMA style (typography etc) A: We have to have the final document at the next meeting (Sept) B: Is there anything we should double check? A: Chapter 10 is significant. All the array and string algorithms were rewritten. A: My sense: There must be bugs in this document. No worse than in ES3 Test suites: Mark: Sputnik and MS ES5 tests test the specs. The moz tests tests mozilla implementation. Should reflect the spec and the structure of the spec Rob: Our concern is that the spec does not match the implementation. Mark: Sputnik tests extensions as well Rob: Mozilla is willing to contribute their tests. Rob: Doing development as an open source project with code reviews etc. Brendan: It doesn't matter where it is hosted Rob: At one point we hope to have enough tests to publish it as a technical report. The project is not an official ECMA project but a future report will be an ECMA branded report. CodePlex should be fine. Mark to ask Christian what his objections are. (more below on hg.ecmascript.org) Implementation testing and break the web testing. Mark believes that Microsoft are coming to a closure on the implementation front. Allen, and others, have been using their prototype for weeks without noticing anything. That doesn't prove anything but it is something. What can we do if we do find a compat issue? John Neumann: We cannot change it after September. Which goes to fast track to ISO. 6 months. Comments can be made during that time. And we can do revisions which will use the same edition number. At next meeting we will approve the spec. Brendan, Rob: Mozilla still implementing, aim to be done before next meeting. Istvan: 2 meetings. Sept (in the bay area, most likely Google), Nov (with w3c). Mark: Wants to distinguish ES6 and Harmony. ES6 is the next concrete spec and Harmony is the general direction. Doug: Don't call it ES6. Group agreement there What are the goals for Harmony? 1-9. The ES3.1 9 goals are still applicable (on the wiki) 10. To provide syntactic conveniences for good abstraction patterns. 11. To provide syntactic conveniences for high integrity patterns. 12. To minimize the additional semantic state needed beyond that provided by ES5 13. Reference implementation? Testable spec. These got moved and cleaned up. The agreed goals and means are available at http://wiki.ecmascript.org/doku.php?id=harmony:harmony http://wiki.ecmascript.org/doku.php?id=harmony:proposals http://wiki.ecmascript.org/doku.php?id=strawman:strawman Cormac: Should an ESH implementation also run ES5? How do they interact? Mark: Suggests ESH runs ES5strict but not necessarily ES5 Mark: use strict puts you in harmony Make sure the language remains approachable by casual scripters. Discussion about int and other number types that are wanted by code generating Allen: First and foremost it is a language for humans const f() {} is syntactic sugar for frozen functions. It would be good if the ES5 object model is good enough for ES3, ES5 and ESH Cormac: Harmony spec needs to spec compat mode with ES5 and strict mode opt in? mark: if (function() { "use strict"; return this; }()) { // < ES5 } else { // ES5 } Allen: Possible time frames for harmony Doug: Gating thing would be implementation, feature wrangling. Testable implementation and test suites and the synchronize that with the ecma calendar Cormac: 2 which ends up being 3 Cormac: There is the whole issue of formalism Allen: We could probably identify some smaller sub problems. Milestone would be to create a reference implementation for ES5 starts with a strawman. then moves to proposals, then specification as a patch Doug: What language. He likes the work Allen has been doing and suggests ES5 as the implementation language. Cormac: Spec ES5 in ES5 (the English prose) Mark: We could say that the interpreter is written in the common subsets of ES5 strict and ES3. Spec. Formalism Use ES3/5s "interpreter" based on Allen Wirf-Brock's work Rewrite ES5 spec using above (1) replace pseudo code with ES code (2) Reorg as appropriate (3) Parser/grammar? Use new "ES5" spec as baseline for Harmony spec Work flow straw man - vague feature/functionality/sketch proposal - "complete" informal spec spec patch - formal spec (Tech Report) Integrated into Harmony spec Brendan: We already have hg.ecmascript.org setup. Mark suggested we host shared Ecma testsuite at hg.ecmascript.org. General agreement, need to confirm with Allen. Catchalls Brendan: We should really get feedback from V8 and Apple and other VM people. Mark: There is another approach to catchalls similar to how it is done in E Allen: Catchalls should be cachable. Catchalls on prototype needs extra care Erik: There is also index getter/setter Brendan: set setMissing ---------------- setIndexed getIndexed Mark: ES4 had List/Vector. Brendan: Maciej also wanted Set set covers the use case. It requires more work than setMissing (setIndexed/getIndexed) but it might be better to start simple. Brendan: a = [] a[(1 << 32) - 2] = 42; a[(1 << 32)] = 43; print(a[0]) => undefined a.length => (1 << 32) -1 Return to label Mark: Still useful even without lambdas. Cormac: What does it give us that exceptions cannot achieve Codify a pattern and make sure that no one catches the exception Hashes/Map Allen: hashCode. Sure it introduces another source of non determinism Mark wants hash tables Mark: It introduces a covert channel Ephemeron weak pointer. has 2 methods. registerExecutor/registerObserver which gets notified when the pointer is null ephemeron table can be used to assign unique ids to objects. Chasing our tail. Mark: The ephemeron table is local so if you don't have a reference to it you cannot get the id Mark: We can introduce a new primitive. A number generator that returns a unique number for object that it is passed in Messages to null - No, it is too late Mark: Can we add modules to strawman or proposal. Brendan: Yes, add to strawman first ByteArray/Blob Nitro has it Canvas wants clamping and rounding Maybe we need bit blit on a new value type Brendan: We need a storage type, not necessarily bitblt operator. Mark: Could byte array be written in the language? Brendan: Yes, with catchalls Mark: Then it is not introducing new semantic state? Allen's concern is that we add a specialized object. Mark: Blob implies immutable, buffer, array implies mutable Allen: Why bytes and not bits? Mark: With bits we get to the endian issue :-) Math.random() Rob: What about an improved random? Mark: What about crypto? Brendan: We (moz) are planning to use their crypto libraries for Math.random(). If we provide something else people will still use Math.random which would still have the potential issue. Doug: We still need a fast random generator. Sam and Brendan countered that CPUs are much faster than in 1995, but Doug could be right. Only way to tell is to try the experiment. Mark: From a security point the issue is that there is a shared state. More Math functions? hypot? log10? Mark: How about a standardized debugging API. Not as part of ECMAScript but something the TC might be interested in. Brendan: There is some work going on in the open web between V8, Spidermonkey and Nitro. It seems like this will happen. Spread Mark: We should also allow spread to be used in object literals to expand let a = {a: 0} let b = {b: 1, ...a} // {b:1, a: 0} let c = {...a, b: 1} // {a: 0, b:1} Array like objects should work. Use same logic as for apply to determine length Mark: { x: x, y: y, ...stuff } enumerable own properties Allen: It is a different semantics with the same operator. Mark: Call it spread-map Allen: This is syntactic sugar to the object literal Brendan cited http://successor-ml.org/index.php?title=Functional_record_extension_and_row_capture at this point (know from ES4 destructuring proposal discussion). Mark: Is the following syntactic sugar conflict free? const { ... } Answer: no, this is destructuring, can't mean frozen object. Allen: {[...], x: x, } in ES4 {const x: ...} Brendan: let o = {x: 0, y: 1} const; Allen: var o = { method f() {} }; it would do binding. SES Mark and Doug came up with this list on an earlier occasion: function objects are frozen function have name property frozen functions do not have prototypes object literals inherits from null % becomes the modulo operator remove ==, remove != remove semicolon insertions remove with changes to eval change the status to ps and ls What to do with |this|? Probably leave it as ES5 strict class Observable() { const listeners = []; public addListener(listener) { listeners.push(listener); } public notify() { for (let i = 0; i < listeners.length; i++) { listeners[i](...); } } } if a listeners references this it gets access to the listeners (1, listeners[i])(...) gets around it. apply etc also gets around it Doug persuaded Mark that the |this| hazard here was tolerable, compared to removing |this| from SES. Big picture conclusion was Doug reevaluating SES in light of agreement to make a statically verifiable obj-cap subset of Harmony be a goal.