Day 2 meeting notes

Waldemar Horwat waldemar at google.com
Tue May 25 16:09:32 PDT 2010


Here are my raw notes from today's meeting.

    Waldemar


Decimal discussion:
Sam:  Can decimal be done as a package?  Yes, if doing it via function
calls is sufficient.  Replacing the behavior of "+" would be harder.
Mark:  Value types not as important as other things that have already
been dropped from ES6.
Doug:  Would want to replace double with decimal, but 754r is too flawed.
Mark:  Disagree with Doug about double but agree that 754r is a non-starter.

Mark:  Proposed proxy changes:

1.  x[y] would call the get method that would not auto-coerce y to a string.
Questions about impact of this on performance: when do implementations
intern strings for property access?  Implementors seem to all do the
coercion/interning relatively early, so thing change would be
inconvenient.
Could this have an effect on the order in which multiple user methods
(such as coercions) can be run as side effects of evaluating an
expression?
Mark withdrew this proposal after discussion.

2.  Recursive fixing.  What happens when fixing a proxy makes a
recursive call to fix the same proxy?  Proposed answer:  Throw a type
error on the inner call.

3.  Changing the iteration trap:  Replace an enumerator with an iterator.
An implementation could provide an efficient way of converting one to the other.
iterator: function () -> {next: function() -> any}
Debate about why this is an object with a next field that contains a
function rather than just a closure.  Some rationale: this makes
iterators more similar to generators that have several fields.
Iterate trap returns an iteration driver.
Lots of confusion about trying to understand the iterator API
proposal, its terminology, and the code on the wiki.  Can't usefully
continue to discuss it until the confusion is cleared up.
Question about performance implications of using exceptions to
terminate iteration.  On the other hand, it is more convenient.
Mark:  Conflict between two levels of abstraction (say nested for-in
iterations), where the outer one wants to throw a StopIteration
exception through the inner one.

Brendan:  Mozilla experimenting with not suppressing deleted
properties from enumeration.  Instead, they'd make a snapshot and
iterate through the snapshot.  This is incompatible with ES5 as
written but ought to work in practice and is much simpler than trying
to track changes in the prototype hierarchy.

Typed arrays:  Consensus that aliasing and exposing endinness are
problems.  Would be more interested in a solution that doesn't suffer
from those.

Shallow continuations:  Not just a syntax change from the last
proposal.  The semantics are different:  finally clauses will not get
called if control escapes out of the function without calling the
continuation.

Waldemar's objections:  A function does something completely different
if anywhere inside it there is a shift or yield expression.  These
non-function-like things should be distinguished (perhaps with a
different keyword than "function").  Would be more amenable to this
proposal if try/catch/finally were not allowed in outer scopes of such
things.

W3C got a request from Google for an ECMAScript internationalization
library.  We should invite these folks to the next meeting.

Simple Modules proposal:
Banishing global object is done by the script tag, not by modules.
module M = Math is similar to const M = Math but with eval-when
:compile semantics.
Controversy over the local renaming syntax:  whether import x.{A:B,
C:D} means A is defined with the value B or B is defined with the
value A.
Inner modules are exported by default.

Remote modules on the web (1) example:  json2.js is a module body, not a module:

// json2.js
import stdlib.{String, ...}
var tmpPrivateThingy = ...
export function Stringify(x) {...}
module Submodule {export function Foo() ...}

Caller:
module JSON = load 'http://json.org/modules/json2.js';
alert(JSON.stringify({'hi': 'world'}));
JSON.Submodule.Foo(...);

Note that json2.js does not name itself at the top level; the caller
gets to name it.  Allen: Some disagreement with that--the module
should get to name itself in the default case.  Doing that that way
would complicate multiple modules in a file though.

Waldemar: How does the json2.js module refer to itself? Answer: it can't?

Unhygienic name capture concern.
Doug:  A widget needs to be able to defend itself from the page.

Filesystem modules for offline ES example has a bunch of bugs.
Top-level modules are superfluous in the example.  Question:  what
happens if one writes var h = io.File.open(...) instead of var h =
open(...)?  If it works, then the file system hierarchy is overlaid
over the variable environment--creating a file in the current
directory will create a variable in the program.  If it doesn't work,
then import does a different lookup from the normal one.

Cyclic dependencies:
Can two script tags have cyclic dependencies? No.

// main file
module Even = load "even.js";
module Odd = load "odd.js";

// odd.js
import Even.*;
export function myOddMethod() ...
...

// even.js
foo = Odd.myOddMethod();
// Note that "Odd" is within scope here!
...

Mark: Objects to resolving ModuleLoader.current() using dynamic
scoping to get the module loader.  Confusion reigns after a bit of
discussion.  What if the call got initiated by the module eval inside
another module eval?  Here it's controversial.  What if it got
initiated by an event handler?  The model doesn't seem to work in this
case yet.
Do we need ModuleLoader.current()?

ModuleLoader uses its "global" parameter only for legacy code uses.

ModuleLoader's "load" parameter is expected to call exactly one of its
three Request functions.  It's an error if it doesn't call any of
them.
rewriteMRL never reinvokes some other user module loader; it only uses
the system one.

evalScript throws an error if it gets an export statement. However, it
permits local modules but does not export them.

Not clear yet how dynamic loading works with mutually recursive modules.


Khronos group joint meeting:  The issues are visible endianness and
aliasing.  Khronos found that the operations that they needed for file
i/o were somewhat distinct from those they needed for graphics work.

Possible alternatives that don't expose endianness:  Lightweight
structs.  Khronos:  it's less efficient to index into those.  Why?

Arrays of structs are preferable to sets of homogeneous element arrays
due to cache and convenience effects.

Allen:  Trade off lots of different views of scalar values vs. a
richer set of SSE-like operations that might be a better semantic
match.  Example:  smalltalk bitblt allowed a rich set of
customizations.

Don't currently have scatter/gather operations.  Would like to have them.

Well-supported arrays of structs (as schemas) might be a satisfactory
compromise.  Consensus emerging around that solution.

Khronos would like to continue developing their API as WebGL host
objects in the meantime.  This may lead to forking of APIs in the
developers' minds.  The possible danger is failure to reuse common
abstractions.

Need a champion.  Waldemar offered to work with Khronos to drive a proposal.


More information about the es-discuss mailing list