Day 1 meeting notes

[Waldemar Horwat]

ECMA needs permanent documentation of proposals to satisfy WTO
requirements.  Proposal is to have ECMA staff take snapshots of the
wiki once the relevant wiki proposal urls are posted.

Microsoft executed an ECMA software license for the test project.

Google is expected to contribute Sputnik.

Two active projects for contributions:  Test262, Harmony.  Use
separate software contribution pro.

Brendan will look into relicensing the ES3/4 grammar and semantic
engine and validator as BSD so it can be part of the Harmony
contribution.

John:  Easiest for TC39 members to just license contributions with BSD
licenses from the start.  Cuts out a lot of the legalese for
collaborative development, needing only one contributor agreement form
from each company for each project.

No response from Philippe to John.

No enthusiasm within the group for traveling to France for a TC39
meeting later this year.

Currently WebIDL has no editor.  There's a vacuum there.

Four different organizations are standardizing ECMAScript binary arrays:
* TC39
* WebGL typed arrays are happening now.  It's too late to affect them.
* HTML5 binary arrays are in an earlier stage.
* There's also NodeJS.
It's awkward to coordinate all of this.

Rex Jaeschke's SC22 liaison document is somewhat out of date -- it
claims that the 3rd edition of ECMA-262 is the current one.

TC39's ES5 comments shall be submitted to JTC1 secretariat.  This
includes some Technical Corrections.  It would be nice if there were
no need for a Ballot Resolution Meeting.  All this falls under the old
ISO procedure because we filed the paperwork before July 1.

If/when ISO approves ES5, we'll backport the changes to the ECMA ES5
document and submit it to the GA as Edition 5.1.  Don't want to name
it "Edition 6" for small errata like these.

Allen:  Should we include the new ECMA BSD software license in ES5.1?
Mark, Waldemar: Yes.  Istvan:  Wants to harmonize with ISO first.


Changes to module proposal from last meeting:
Nested modules have access to the complete lexical environment (not
just the module bindings) of their parent modules.

The external modules slideshow is new, not yet reflected on the wiki.

module MyLib {
  function log(x) {...}
  module Util {
    module Even = load "even.js";
    module Odd = load "odd.js";
  }
}
This is like compile-time textual inclusion except that even.js and
odd.js don't have access to the bindings MyLib, log, and Util.
However, odd.js has access to the binding of Even and even.js has
access to the binding of Odd.

    module Even = load "even.js";
    module Odd = load "odd.js";
    module Imaginary = load "even.js";
This creates two entirely separate copies of even.js.

Load is like textual inclusion, not like an import:
even.js:
module Odd = load "odd.js"

odd.js:
module Even = load "even.js";
This blows up due to infinite inclusion.

Free variables inside odd.js and even.js are assumed to be module
references.  This stirred up controversy.

even.js:
module A = load "foo.js"

foo.js:
import Odd.*  // Doesn't resolve Odd

To fix it:
even.js:
module Odd = Odd;
module A = load "foo.js"

foo.js:
import Odd.*  // Doesn't resolve Odd

except that "module Odd = Odd" doesn't work because modules are
letrec-bound.  Proposed fix: introduce a special syntax for
reexporting a module:
module Odd;

Now, what if instead of "module Odd = Odd", one wanted to express
something with the effect of "module Odd = Odd.SubOdd"?

Evaluation time expository example:
module A {...};
module B = C.foo;
module C = load "c.js";
works because the module B = ... statement doesn't do anything at run
time.  However,
module A {...};
module B = C.foo;
B.doSomething();
module C = load "c.js";
doesn't work because B is not defined by the time doSomething is invoked on it.

This also means that even.js cannot use "Odd" at the top level in the
original example.

Question about what the following means in simple_modules on wiki:  "A
program is a sequence of scripts, evaluated from top to bottom. Each
script is evaluated in a nested declarative environment record."

Possible answer:  Each subsequent script on a web page is nested
inside the prior one.
Objections:  This is weird.  A let statement can shadow a let
statement using the same name.  This is counterintuitive for sibling
scripts on a page.  Having a flat scope for the collection of scripts
on a web page would be better.

The above means that the top-level scope can be extended dynamically.
This might clash with any predefined meaning of free variables such as
considering them to be references to modules; it was a major hassle in
ES4.

Why do we need overridable enumerators when we have overridable iterators?
Point:  because one returns only strings that are property names while
the other returns arbitrary data.
Counterpoint:  If that's the criterion, then we shouldn't be using the
for-in syntax for both.  Leads to exactly the same problems when you
think you're doing a for-in over properties when you're in fact
getting values.

Error prone:  for (x in Iterator.values([1,2,3,4,5])) vs. likely
programming error for (x in [1,2,3,4,5])

Waldemar:  If they are separate concepts, using the same for-in syntax
for iteration and enumeration is too error-prone.  If you intend to
iterate on object Foo but accidentally pass in a Foo that's not an
iterator, you'll get its property names instead of a visible error.
It's particularly insidious with arrays.

Mozilla's recent trials:  Changing the behavior of enumeration to a
pure snapshot order under concurrent modification of the iterated
object turned out to be a breaking change.  People use object
properties as work lists and sometimes delete future work list items.
Mozilla's current trial is an "ugly" and hard-to-describe
deletion-filtering order that handles deletion on the direct object
but not across the prototype chain.  Too implementation-specific to
make it suitable for a standard.

Conclusion:  Futile to exactly specify enumeration order in obscure cases?

Proposed enumeration order:
1.  Numeric order across all prototypes (entries that are considered
to be array indices)
2.  Prototype chain order
3.  Creation order
Debate and some incredulity over scanning the prototype chain twice.
Prototype chain order should be the primary order, not secondary.

Behavior of what happens when the iterated object is modified is still unclear.

Why is there a need for both next() and send() in the iteration
protocol?  Seems like unnecessary historical complexity.

Generators discussion.