es-discuss Digest, Vol 41, Issue 9

[Brendan Eich]

On Jul 4, 2010, at 4:37 AM, Leo Meyerovich wrote:

> Ah, I was confused by the use of bootstrap in "Could we bootstrap Set, Map, and WeakMap and call it enough?" ; I thought you meant a user-level encoding of these given language-level hashes etc.

The strong maps could be efficiently built in "user code" with Object.hashcode/identity. The committee would have a relatively easy time getting those specified, and implementors would find them relatively easy to implement, compared to higher-level and more extensive APIs. Then library authors could start using them.

The point is that TC39 does not want to invent library code if we can defer to the ecosystem and then de-jure-standardize what emerges as good de-facto standard API.

But then JS users always (for many years, anyway) have to download some code. This is inevitable, although no excuse for not standardizing promptly: downrev browsers will require a download to patch in or around missing APIs; uprev could provide a built-in module. (Details of the module system -- simple modules in the wiki -- aim to address this issue.)

So when I wrote "bootstrap" I meant that TC39 might take a bit more risk de-jure-specifying Set and Map along with WeakMap, instead of just providing Object.{hashcode,identity} and waiting for evolution to do the rest.

There's a delicate dance between library authors and the core language maintainers. You can see this with bind in several libraries (sometimes called something else; API details vary) vs. ES5's Function.prototype.bind. We're still learning, by doing as much as studying what is out there.


> Found the table proposal.. without iteration (and assuming no weak ptrs), one of my main use cases (data flow constructs), is still restricted. Given other proposals like object hashing, I'm not sure how much of a win these tables are. If the reason they're not there is non-determinism, weak ptrs would make this a non-issue.

Weak pointers have a leak hazard fixed by Ephemerons when you tie a cyclic knot among keys and values in a table (http://wiki.ecmascript.org/doku.php?id=strawman:weak_references discusses this).

Weak pointers may also leak GC schedule and liveness -- very much "deteriminism", not ND -- by hooking post-mortem finalization. Thus the interest in Ephemerons.


> Furthermore, I suspect numerics already introduce non-deterministism and embeddings of JS push most programs towards it as well (browsers, servers, games), so purism would be a Quixotian goal.

I happen to agree at the limit, but the argument is not as absolutist as you might think. Mark argues that even with the ND legacies in the language, we should strive to avoid adding more. This is not a bad guideline as far as it goes.


> Assuaging some concerns, iteration can be phrased as a capability (and thus disabled) and not made generic (preventing unintended encountering such as preventing it from hitting generic for-in sugar).


Iteration based on harmony:proxies (http://wiki.ecmascript.org/doku.php?id=strawman:iterators) is looking good, but ETs should not be enumerable at all.

First, we should agree on the memory bloat/leak hazard, along with the post-mortem finalization "leak", of weak ptrs being sufficient cause to want ETs instead.

/be