Last weeks meeting notes

Erik Arvidsson erik.arvidsson at gmail.com
Mon Aug 3 10:21:35 PDT 2009


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.


More information about the es-discuss mailing list