Khronos: standard-setting consortium
Khronos standards are royalty-free (any essential patents must also be
royalty-free).
We'll have a joint meeting with them on Tuesday 3PM.
Khronos categories of members: adopters and implementors.
Implementors get a test suite. For the technology under discussion
the test suite would be free.
No relationship between Khronos and W3C.
Dr. SES = Distributed Resilient Secure ECMAScript
Istvan described the upcoming ECMA policy on submission and licensing
software. Note that "software" includes pseudocode such as that used
in ES5.
That policy applies only to future standards.
ECMA standards will come with a BSD license for any included software.
No contact between Sam and Mark about decimal.
Mark interested in value types but says there is no pressing need for
them in ES6.
Due to lack of interest, decimal will likely not be a candidate for
inclusion in the next version of ECMAScript.
ES5 erratum highlights:
String indices subject to 2^32 limits and they shouldn't be?
The committee agrees that nonenumerable properties should shadow
enumerable ones when enumerating. Some think that the standard text
already states that, others think it could use slight clarification.
ECMA 357 should be revised or obsoleted by December 2013. It has some
problematic features such as its with-on-steroids.
Maybe ECMA 357 can be "proxified" to be implemented with Harmony.
Some of its features would need to go to make that happen, such as its
distinction between method get and method call.
The conformance test suite will likely be an ongoing project rather
than stopping at the TR. However, the TR is needed to make it an
official ECMA-approved publication.
No news about joint W3C meeting in November. No significant interest
in a face-to-face meeting in France in November.
Primary area of concern: WebIDL and its ECMAScript language binding.
Specification language: Debate about whether using ECMAScript for the
specification language is appropriate. Some issues:
How to define "if" in terms of "if", "<=" in terms of "<=", etc.
Much of the language would be circular in this way.
Many opportunities for accidents. The "+" operator can add numbers,
concatenate strings, etc., and it's not clear which one is being used
in pseudocode. One might accidentally concatenate instead of adding
when specifying an algorithm.
Confusion between the specification language and the specified language.
Counterpoint: Use ES5 to specify the specification language.
Countercounterpoint: Shouldn't refer to obsolete versions of the
standard normatively. Also want to be able to express new data
structures from within pseudocode.
Allen and Waldemar: Useful to have a reference implementation in some
specification language and develop that in parallel with the
specification. However, the specification need not be written in the
same language. One way to do this is to have a single source S and
mappings from S to an executable reference implementation (not part of
the spec) and from S to the spec. The latter mapping is not
bijective.
Consensus: The status quo seems attractive to many in the committee.
Oliver: the status quo pseudocode in ES5 worked better for him as an
implementor than any code he's seen.
Allen: Would be helpful to clean up chapter 8.
Waldemar will revive the Common Lisp semantic code, particularly the
parser and grammar checkers by the next meeting.
Mark: No need for new in-band opt-ins. Might want an out-of-band
opt-in to keep old browsers from trying to execute "let" statements
and such.
Mark concerned about existing browser practice with named nested
function declarations. There is no common semantics. Brendan:
Mozilla will change to conform to whatever the committee reaches
consensus on in such cases.
Mark will do a writeup for const and let variable declarations and
nested named functions. We've had a verbal agreement on these for a
long time.
Past agreements: Functions are hoisted to the top of a block and
initialized before the block begins execution. Functions are
let-bound, not const-bound. Consts are block-scoped and have a
temporal dead zone where accessing them would cause an exception.
Themes: Consensus with the idea of having themes and filtering
proposals based on them, but disagreement on the specific choice of
themes. Missing: abstraction/data structuring/classes,
internationalization.
Submit wiki write permission requests to Brendan.
Discussion about classes. Mark will revive the proposal.
Waldemar: Key requirements for classes: Unforgeable trademarking,
object shaping, not creating O(n*m) objects for n instances with m
methods.
Great debate over whether modules or classes should be the top
priority for Harmony.
Naming discussion on EphemeronTable: It shouldn't be called
WeakKeyTable because the latter has a well-defined meaning--it can't
collect cycles like {Key1->Key2, Key2->Key1}.
Mark's ephemeron tables conflate storing undefined as a value with not
having a binding at all. One deletes a binding by setting its value
to undefined. This means that the example of walking the prototype
chain doesn't work for undefined values.
Ephemerons retain the invisibility of garbage collection. Enumeration
of ephemeron tables (currently disallowed) would make gc observable.
Allen: Levels of impact on gc (and therefore on system performance):
Identity-based hash tables: none
Weak-keyed tables: more global impact; special processing
Ephemeron tables: larger impact; addresses cycle problem
Waldemar: There's also a level 0 (class-private fields), which would
have even less impact because it does not need an identity-based hash
table at all. Level 0 is sufficient to implement things like the
money/purse ephemeron example.
Question: Do the extra costs of ephemeron tables over weak key tables
appear even if there are no cycles that an ephemeron table would
collect but a weak key table wouldn't?
Answer: No; the two tables should have equivalent performance in that
case. However, it is possible to carry out denial-of-service attacks
by creating pathological ephemeron cycles.
Ephemeron tables dominate weak-key tables. There's little reason to
have the latter if we have the former. Identity-based hash tables
might be useful on their own.
Agreed to move the status of ephemeron tables from strawman to
proposal. Implementors reluctant with trying strawmen may now
experiment with implementations of ephemeron tables to try to figure
out what issues would arise. The two open issues are
delete-vs-undefined and the name of the abstraction.
Tail calls: It's very hard to make any claims about space complexity
or even reachability of tail calls. There's a research project which
came up with a complicated framework for making such claims, but it's
probably too much for our spec.
Even the following is not currently clearly defined: Function F has
local variables X and Y. A closure capturing X escapes. F returns.
Is Y live or not? Would need to define this first.
Allen: Tail calls would have slow uptake among implementors.
Tail calls are hard to do in Rhino.
No consensus on tail calls.
Agreed to let let expressions move to the graveyard. They don't carry
much weight and seem like a grab bag feature.
Here are my notes for today's meeting.
Waldemar
Khronos: standard-setting consortium
Khronos standards are royalty-free (any essential patents must also be
royalty-free).
We'll have a joint meeting with them on Tuesday 3PM.
Khronos categories of members: adopters and implementors.
Implementors get a test suite. For the technology under discussion
the test suite would be free.
No relationship between Khronos and W3C.
Dr. SES = Distributed Resilient Secure ECMAScript
Istvan described the upcoming ECMA policy on submission and licensing
software. Note that "software" includes pseudocode such as that used
in ES5.
That policy applies only to future standards.
ECMA standards will come with a BSD license for any included software.
No contact between Sam and Mark about decimal.
Mark interested in value types but says there is no pressing need for
them in ES6.
Due to lack of interest, decimal will likely not be a candidate for
inclusion in the next version of ECMAScript.
ES5 erratum highlights:
- String indices subject to 2^32 limits and they shouldn't be?
- The committee agrees that nonenumerable properties should shadow
enumerable ones when enumerating. Some think that the standard text
already states that, others think it could use slight clarification.
ECMA 357 should be revised or obsoleted by December 2013. It has some
problematic features such as its with-on-steroids.
Maybe ECMA 357 can be "proxified" to be implemented with Harmony.
Some of its features would need to go to make that happen, such as its
distinction between method get and method call.
The conformance test suite will likely be an ongoing project rather
than stopping at the TR. However, the TR is needed to make it an
official ECMA-approved publication.
No news about joint W3C meeting in November. No significant interest
in a face-to-face meeting in France in November.
Primary area of concern: WebIDL and its ECMAScript language binding.
Specification language: Debate about whether using ECMAScript for the
specification language is appropriate. Some issues:
- How to define "if" in terms of "if", "<=" in terms of "<=", etc.
Much of the language would be circular in this way.
- Many opportunities for accidents. The "+" operator can add numbers,
concatenate strings, etc., and it's not clear which one is being used
in pseudocode. One might accidentally concatenate instead of adding
when specifying an algorithm.
- Confusion between the specification language and the specified language.
Counterpoint: Use ES5 to specify the specification language.
Countercounterpoint: Shouldn't refer to obsolete versions of the
standard normatively. Also want to be able to express new data
structures from within pseudocode.
Allen and Waldemar: Useful to have a reference implementation in some
specification language and develop that in parallel with the
specification. However, the specification need not be written in the
same language. One way to do this is to have a single source S and
mappings from S to an executable reference implementation (not part of
the spec) and from S to the spec. The latter mapping is not
bijective.
Consensus: The status quo seems attractive to many in the committee.
Oliver: the status quo pseudocode in ES5 worked better for him as an
implementor than any code he's seen.
Allen: Would be helpful to clean up chapter 8.
Waldemar will revive the Common Lisp semantic code, particularly the
parser and grammar checkers by the next meeting.
Mark: No need for new in-band opt-ins. Might want an out-of-band
opt-in to keep old browsers from trying to execute "let" statements
and such.
Mark concerned about existing browser practice with named nested
function declarations. There is no common semantics. Brendan:
Mozilla will change to conform to whatever the committee reaches
consensus on in such cases.
Mark will do a writeup for const and let variable declarations and
nested named functions. We've had a verbal agreement on these for a
long time.
Past agreements: Functions are hoisted to the top of a block and
initialized before the block begins execution. Functions are
let-bound, not const-bound. Consts are block-scoped and have a
temporal dead zone where accessing them would cause an exception.
Themes: Consensus with the idea of having themes and filtering
proposals based on them, but disagreement on the specific choice of
themes. Missing: abstraction/data structuring/classes,
internationalization.
Submit wiki write permission requests to Brendan.
Discussion about classes. Mark will revive the proposal.
Waldemar: Key requirements for classes: Unforgeable trademarking,
object shaping, *not* creating O(n*m) objects for n instances with m
methods.
Great debate over whether modules or classes should be the top
priority for Harmony.
Naming discussion on EphemeronTable: It shouldn't be called
WeakKeyTable because the latter has a well-defined meaning--it can't
collect cycles like {Key1->Key2, Key2->Key1}.
Mark's ephemeron tables conflate storing undefined as a value with not
having a binding at all. One deletes a binding by setting its value
to undefined. This means that the example of walking the prototype
chain doesn't work for undefined values.
Ephemerons retain the invisibility of garbage collection. Enumeration
of ephemeron tables (currently disallowed) would make gc observable.
Allen: Levels of impact on gc (and therefore on system performance):
1. Identity-based hash tables: none
2. Weak-keyed tables: more global impact; special processing
3. Ephemeron tables: larger impact; addresses cycle problem
Waldemar: There's also a level 0 (class-private fields), which would
have even less impact because it does not need an identity-based hash
table at all. Level 0 is sufficient to implement things like the
money/purse ephemeron example.
Question: Do the extra costs of ephemeron tables over weak key tables
appear even if there are no cycles that an ephemeron table would
collect but a weak key table wouldn't?
Answer: No; the two tables should have equivalent performance in that
case. However, it is possible to carry out denial-of-service attacks
by creating pathological ephemeron cycles.
Ephemeron tables dominate weak-key tables. There's little reason to
have the latter if we have the former. Identity-based hash tables
might be useful on their own.
Agreed to move the status of ephemeron tables from strawman to
proposal. Implementors reluctant with trying strawmen may now
experiment with implementations of ephemeron tables to try to figure
out what issues would arise. The two open issues are
delete-vs-undefined and the name of the abstraction.
Tail calls: It's very hard to make any claims about space complexity
or even reachability of tail calls. There's a research project which
came up with a complicated framework for making such claims, but it's
probably too much for our spec.
Even the following is not currently clearly defined: Function F has
local variables X and Y. A closure capturing X escapes. F returns.
Is Y live or not? Would need to define this first.
Allen: Tail calls would have slow uptake among implementors.
Tail calls are hard to do in Rhino.
No consensus on tail calls.
Agreed to let let expressions move to the graveyard. They don't carry
much weight and seem like a grab bag feature.
Here are my notes for today's meeting.
Khronos: standard-setting consortium Khronos standards are royalty-free (any essential patents must also be royalty-free). We'll have a joint meeting with them on Tuesday 3PM. Khronos categories of members: adopters and implementors. Implementors get a test suite. For the technology under discussion the test suite would be free. No relationship between Khronos and W3C.
Dr. SES = Distributed Resilient Secure ECMAScript
Istvan described the upcoming ECMA policy on submission and licensing software. Note that "software" includes pseudocode such as that used in ES5. That policy applies only to future standards. ECMA standards will come with a BSD license for any included software.
No contact between Sam and Mark about decimal. Mark interested in value types but says there is no pressing need for them in ES6. Due to lack of interest, decimal will likely not be a candidate for inclusion in the next version of ECMAScript.
ES5 erratum highlights:
ECMA 357 should be revised or obsoleted by December 2013. It has some problematic features such as its with-on-steroids. Maybe ECMA 357 can be "proxified" to be implemented with Harmony. Some of its features would need to go to make that happen, such as its distinction between method get and method call.
The conformance test suite will likely be an ongoing project rather than stopping at the TR. However, the TR is needed to make it an official ECMA-approved publication.
No news about joint W3C meeting in November. No significant interest in a face-to-face meeting in France in November.
Primary area of concern: WebIDL and its ECMAScript language binding.
Specification language: Debate about whether using ECMAScript for the specification language is appropriate. Some issues:
Allen and Waldemar: Useful to have a reference implementation in some specification language and develop that in parallel with the specification. However, the specification need not be written in the same language. One way to do this is to have a single source S and mappings from S to an executable reference implementation (not part of the spec) and from S to the spec. The latter mapping is not bijective.
Consensus: The status quo seems attractive to many in the committee. Oliver: the status quo pseudocode in ES5 worked better for him as an implementor than any code he's seen.
Allen: Would be helpful to clean up chapter 8.
Waldemar will revive the Common Lisp semantic code, particularly the parser and grammar checkers by the next meeting.
Mark: No need for new in-band opt-ins. Might want an out-of-band opt-in to keep old browsers from trying to execute "let" statements and such.
Mark concerned about existing browser practice with named nested function declarations. There is no common semantics. Brendan: Mozilla will change to conform to whatever the committee reaches consensus on in such cases.
Mark will do a writeup for const and let variable declarations and nested named functions. We've had a verbal agreement on these for a long time.
Past agreements: Functions are hoisted to the top of a block and initialized before the block begins execution. Functions are let-bound, not const-bound. Consts are block-scoped and have a temporal dead zone where accessing them would cause an exception.
Themes: Consensus with the idea of having themes and filtering proposals based on them, but disagreement on the specific choice of themes. Missing: abstraction/data structuring/classes, internationalization.
Submit wiki write permission requests to Brendan.
Discussion about classes. Mark will revive the proposal.
Waldemar: Key requirements for classes: Unforgeable trademarking, object shaping, not creating O(n*m) objects for n instances with m methods.
Great debate over whether modules or classes should be the top priority for Harmony.
Naming discussion on EphemeronTable: It shouldn't be called WeakKeyTable because the latter has a well-defined meaning--it can't collect cycles like {Key1->Key2, Key2->Key1}.
Mark's ephemeron tables conflate storing undefined as a value with not having a binding at all. One deletes a binding by setting its value to undefined. This means that the example of walking the prototype chain doesn't work for undefined values.
Ephemerons retain the invisibility of garbage collection. Enumeration of ephemeron tables (currently disallowed) would make gc observable.
Allen: Levels of impact on gc (and therefore on system performance):
Question: Do the extra costs of ephemeron tables over weak key tables appear even if there are no cycles that an ephemeron table would collect but a weak key table wouldn't? Answer: No; the two tables should have equivalent performance in that case. However, it is possible to carry out denial-of-service attacks by creating pathological ephemeron cycles.
Ephemeron tables dominate weak-key tables. There's little reason to have the latter if we have the former. Identity-based hash tables might be useful on their own.
Agreed to move the status of ephemeron tables from strawman to proposal. Implementors reluctant with trying strawmen may now experiment with implementations of ephemeron tables to try to figure out what issues would arise. The two open issues are delete-vs-undefined and the name of the abstraction.
Tail calls: It's very hard to make any claims about space complexity or even reachability of tail calls. There's a research project which came up with a complicated framework for making such claims, but it's probably too much for our spec.
Even the following is not currently clearly defined: Function F has local variables X and Y. A closure capturing X escapes. F returns. Is Y live or not? Would need to define this first.
Allen: Tail calls would have slow uptake among implementors.
Tail calls are hard to do in Rhino.
No consensus on tail calls.
Agreed to let let expressions move to the graveyard. They don't carry much weight and seem like a grab bag feature.
Here are my notes for today's meeting. Waldemar Khronos: standard-setting consortium Khronos standards are royalty-free (any essential patents must also be royalty-free). We'll have a joint meeting with them on Tuesday 3PM. Khronos categories of members: adopters and implementors. Implementors get a test suite. For the technology under discussion the test suite would be free. No relationship between Khronos and W3C. Dr. SES = Distributed Resilient Secure ECMAScript Istvan described the upcoming ECMA policy on submission and licensing software. Note that "software" includes pseudocode such as that used in ES5. That policy applies only to future standards. ECMA standards will come with a BSD license for any included software. No contact between Sam and Mark about decimal. Mark interested in value types but says there is no pressing need for them in ES6. Due to lack of interest, decimal will likely not be a candidate for inclusion in the next version of ECMAScript. ES5 erratum highlights: - String indices subject to 2^32 limits and they shouldn't be? - The committee agrees that nonenumerable properties should shadow enumerable ones when enumerating. Some think that the standard text already states that, others think it could use slight clarification. ECMA 357 should be revised or obsoleted by December 2013. It has some problematic features such as its with-on-steroids. Maybe ECMA 357 can be "proxified" to be implemented with Harmony. Some of its features would need to go to make that happen, such as its distinction between method get and method call. The conformance test suite will likely be an ongoing project rather than stopping at the TR. However, the TR is needed to make it an official ECMA-approved publication. No news about joint W3C meeting in November. No significant interest in a face-to-face meeting in France in November. Primary area of concern: WebIDL and its ECMAScript language binding. Specification language: Debate about whether using ECMAScript for the specification language is appropriate. Some issues: - How to define "if" in terms of "if", "<=" in terms of "<=", etc. Much of the language would be circular in this way. - Many opportunities for accidents. The "+" operator can add numbers, concatenate strings, etc., and it's not clear which one is being used in pseudocode. One might accidentally concatenate instead of adding when specifying an algorithm. - Confusion between the specification language and the specified language. Counterpoint: Use ES5 to specify the specification language. Countercounterpoint: Shouldn't refer to obsolete versions of the standard normatively. Also want to be able to express new data structures from within pseudocode. Allen and Waldemar: Useful to have a reference implementation in some specification language and develop that in parallel with the specification. However, the specification need not be written in the same language. One way to do this is to have a single source S and mappings from S to an executable reference implementation (not part of the spec) and from S to the spec. The latter mapping is not bijective. Consensus: The status quo seems attractive to many in the committee. Oliver: the status quo pseudocode in ES5 worked better for him as an implementor than any code he's seen. Allen: Would be helpful to clean up chapter 8. Waldemar will revive the Common Lisp semantic code, particularly the parser and grammar checkers by the next meeting. Mark: No need for new in-band opt-ins. Might want an out-of-band opt-in to keep old browsers from trying to execute "let" statements and such. Mark concerned about existing browser practice with named nested function declarations. There is no common semantics. Brendan: Mozilla will change to conform to whatever the committee reaches consensus on in such cases. Mark will do a writeup for const and let variable declarations and nested named functions. We've had a verbal agreement on these for a long time. Past agreements: Functions are hoisted to the top of a block and initialized before the block begins execution. Functions are let-bound, not const-bound. Consts are block-scoped and have a temporal dead zone where accessing them would cause an exception. Themes: Consensus with the idea of having themes and filtering proposals based on them, but disagreement on the specific choice of themes. Missing: abstraction/data structuring/classes, internationalization. Submit wiki write permission requests to Brendan. Discussion about classes. Mark will revive the proposal. Waldemar: Key requirements for classes: Unforgeable trademarking, object shaping, *not* creating O(n*m) objects for n instances with m methods. Great debate over whether modules or classes should be the top priority for Harmony. Naming discussion on EphemeronTable: It shouldn't be called WeakKeyTable because the latter has a well-defined meaning--it can't collect cycles like {Key1->Key2, Key2->Key1}. Mark's ephemeron tables conflate storing undefined as a value with not having a binding at all. One deletes a binding by setting its value to undefined. This means that the example of walking the prototype chain doesn't work for undefined values. Ephemerons retain the invisibility of garbage collection. Enumeration of ephemeron tables (currently disallowed) would make gc observable. Allen: Levels of impact on gc (and therefore on system performance): 1. Identity-based hash tables: none 2. Weak-keyed tables: more global impact; special processing 3. Ephemeron tables: larger impact; addresses cycle problem Waldemar: There's also a level 0 (class-private fields), which would have even less impact because it does not need an identity-based hash table at all. Level 0 is sufficient to implement things like the money/purse ephemeron example. Question: Do the extra costs of ephemeron tables over weak key tables appear even if there are no cycles that an ephemeron table would collect but a weak key table wouldn't? Answer: No; the two tables should have equivalent performance in that case. However, it is possible to carry out denial-of-service attacks by creating pathological ephemeron cycles. Ephemeron tables dominate weak-key tables. There's little reason to have the latter if we have the former. Identity-based hash tables might be useful on their own. Agreed to move the status of ephemeron tables from strawman to proposal. Implementors reluctant with trying strawmen may now experiment with implementations of ephemeron tables to try to figure out what issues would arise. The two open issues are delete-vs-undefined and the name of the abstraction. Tail calls: It's very hard to make any claims about space complexity or even reachability of tail calls. There's a research project which came up with a complicated framework for making such claims, but it's probably too much for our spec. Even the following is not currently clearly defined: Function F has local variables X and Y. A closure capturing X escapes. F returns. Is Y live or not? Would need to define this first. Allen: Tail calls would have slow uptake among implementors. Tail calls are hard to do in Rhino. No consensus on tail calls. Agreed to let let expressions move to the graveyard. They don't carry much weight and seem like a grab bag feature.