Nov 18 notes

Brendan Eich brendan at
Tue Nov 23 11:12:21 PST 2010

On Nov 23, 2010, at 12:11 AM, Maciej Stachowiak wrote:

> One possibility is to add a space as apparently a few other languages do:
> for each (var i in x)
> Should be unambiguously parsable and easy to understand.

This is what ECMA-357, E4X, does, and it indeed iterates values not keys. The obvious criticism is that nothing except (dubious) history says for-in == keys while for-each-in == values. Other symmetries break down:

  for (i in o) assert(i in o)

lacks this parallel construct:

  for each (v in o) assert(o[what-was-v's-name-again?] === v)

JS1.7 allowed key-value destructuring

  for ([k, v] in o) assert(o[k] === v) // assume idemptotent has/get

but this broke a different symmetry:

  for ([s, v, o] in tripledb) ...

which wants other destructuring patterns to destructure the value returned by the iterator. Making the two-element-array destructuring pattern mean key-value destructuring frustrates people who want to iterate over a pairdb. So we fixed this in JS1.8, and dherman's iterator proposal has

  for (k in keys(o)) ...
  for (v in values(o)) ...
  for ([k, v] in properties(o)) ...

EIBTI once again.

>> Anyway, the bikeshed is secondary. We need to agree on what meta-programmable for-in means with the enumerate trap (specified by the wiki pages on harmony:proxies), how that changes with the optional iterate trap (strawman:iterators), and when it might matter (for all for-in loops, or only those in Harmony code?).
> Fair enough. Another important question is whether should continue to guarantee that all values enumerated would be strings. Preserving that guarantee clearly makes useless for the strawman:iterators purpose,

Not quite, as Andreas already argued and (I see, reading ahead) reiterates with dherman adding emphasis.

Stringifying is not good for iterating arbitrary values, in particular property values or key-value pairs, of course. But if you insist (I don't) that for-in always stringify, forever, there are still lazy use-cases for the proposed iterate trap.

> but not for the harmony:proxies enumeration trap (and thus iterators would need new syntax to be usable).  Breaking the guarantee may cause problems for existing code. Breaking the guarantee only in Harmony mode creates additional migration tax. Thus, iterators create a potential motive for new syntax that the proxy enumeration trap does not. 

We're going in circles. Clearly, we could add new syntax. It's also conceivable that we could extend for-in. Trade-offs abound and data on usability hazards is absent in our experience (JS1.7 and up).

> Given this, it is useful to identify candidate syntax that doesn't have perceived showstopper problems, so that we can evaluate the tradeoffs among the three prongs of the trilemma.

It's a problem if showstopper criteria are not shared in a committee. Then anyone can stop the show based on divergent principles or unarticulated beliefs.

It therefore seems more important to achieve consensus on principles, and less important to force new syntax as a compromise that may be founded on bad committee game theory.

> (As an even more concrete previously mentioned example, a new syntax allows sane defaults for arrays without breaking compatibility for the existing construct.)

Mozilla-specific JS hackers do use

  for each (v in a) ...

to iterate values in an array |a|. This is better than

  for (i in a) { v = a[i]; ... }

but it's not so much better that TC39 members are happy to adopt for-each-in from ECMA-357. Maybe we will, in the end. It is overlong and "each" is redundant or ambiguous (take your pick), but at this point it beats the rushed for-: ugliness of last week.


More information about the es-discuss mailing list