Nov 18 notes

Waldemar Horwat
Thu Nov 18 16:08:32 PST 2010
Third day rough meeting notes.


instanceof trap for proxies:  Withdrawn.  Agreed to drop it for now.

Proxy default forwarding handler.  Agreed that there should be an easy
way to delegate to a default forwarding handler.
Waldemar: Why not use prototypes to do this?
MarkM, others: Would work, but need to write a proposal for it.

MarkM: Arguing for simplicity (understandability) of the modules proposal

Discussed the merits of modules, asynchrony, scoping, and evaluation
phasing.  Agreed that static resolution of bindings should produce
results indistinguishable from later dynamic resolution of those
bindings.  Thus, for example it's not ok to asynchronously import *
into an outer lexical scope.  Also need to ensure that asynchronously
loading multiple scripts on a page doesn't violate this rule for the
outer lexical scopes, perhaps by making the "global" scope no longer
be reflected as an object.

DaveH:  Would like to see Harmony lexically scoped all the way up.

Discussion of IEEE 754r decimal cohorts.

Debate over whether for-in should be conceptually restricted to
iterating only keys or whether users should be able to do things like:
for (var val = values(x)
Other points of contention:
Iterating keys of an array should return numbers or strings?
What should be the syntax for general iteration?
Provide a different syntax for user-defined iteration?  for (var key :
Provide a way to iterate only the shallow enumerable properties of an object?

Consensus that we should have iterators.

Generators: Need to have a distinctive syntax in the preamble to
distinguish them from functions.
Finally inside generators is also an issue because it might not run.
Waldemar: don't allow yield inside a try.

Binary data: We have array buffers (not on wiki) and the binary data
spec on wiki.  Array buffers allow accidental aliasing and endian
dependence, and we'd like to not have them.

Two very distinct use cases:
WebGL arrays: endian-ignorant, fixed size, preallocated
File parsing and other such I/O: need to explicitly specify
endianness, dynamically construct representation, deal with
variable-sized items such as strings.  Endianness is a property of the
i/o routines, not of the underlying data buffer.

An arraybuffer is like a void* -- it's a container for view data
structures to index into, where those other data structures impose a
structure on a slice of the arraybuffer.
DaveH: Would be good to enforce no aliasing of views into arraybuffers.

Debate over what primitives should be supported:

Waldemar:  In-memory contiguous buffers that allow pointers to simple
things such as strings.  Example with three congiguous records:
char* -> "Hello"
char* -> "World"
char* -> "\n"
Each record is fixed-size and has a fixed contiguous structure but
whose layout and exact byte size is otherwise invisible to the
ECMAScript programmer.  The records contain pointers to the strings,
but the strings themselves are stored somewhere else on the heap.
There should be no way to read/write these into a file except by
explicitly describing how it's serialized or deserialized.  Of course,
all this could also be done using traditional ECMAScript arrays and
objects but at a much higher cost when the data is things like
graphics data.

DaveH:  An in-memory array of bytes (like an arraybuffer) together
with ways to map views onto it to interpret things like ints, strings,
or offset-pointers in some external data format (such as a JPEG).

Waldemar's objections to providing views into an in-memory array of bytes:
- There is a huge menagerie of basic data types used in files: Many
different kinds of string termination, many different kinds of offsets
and record counts, computed lengths, etc.
- This structure is not appropriate for general modifications.  An
ECMAScript program cannot practically insert something into the middle
without adjusting offsets, lengths, etc. in the block records around
the inserted data.  Instead, the offsets, lengths, etc. should be
consumed by deserialization and generated by serialization.

Turns out that the GL interface doesn't let ECMAScript write directly
into GPU memory.  The methods make copies as needed.

More discussion of data buffers.

More information about the es-discuss mailing list