Day 2 meeting notes

Brendan Eich brendan at mozilla.com
Thu Jul 29 19:04:49 PDT 2010


On Jul 29, 2010, at 4:55 PM, Oliver Hunt wrote:

> On Jul 29, 2010, at 2:47 PM, Waldemar Horwat wrote:
> 
>> Comprehensions:  To be useful, need to have a bunch of basic helpers
>> such as range(), properties(), values(), etc. with short names that
>> can be used to construct comprehensions.  These will be added to the
>> proposal.
>> 
>> Would like to be able to interleave for and if clauses:
>> [x*y for (x in range(...)) if (isprime(x)) for (y in range(x+1...)) if
>> (isprime(y))]
> 
> I keep seeing code like this, I simply don't see it as viable to have "for (.. in ...)" sometimes enumerate property names, and some times enumerate keys, it seems like it could be both confusing and error prone.  esp. given the simplest example: [x for (value in [1,2,3])] you would not get the desired behaviour, unless in comprehensions for(in) behaves differently from everywhere else.
> 
> It seems far better to just define a distinct syntax for enumerating values of an object.

This, if I understand correctly, is Waldemar's position as well.

On the other side both Python and JS1.7 and up in SpiderMonkey and Rhino make for-in meta-programmable. Python however makes sequence types by fiat iterate values, not keys, where sequence type includes list, which is []-bracketed like JS array initialisers.

The counter-argument is that the language has coveted syntax, for-in, which has broken semantics, and rather than essentially abandon it, we should *reform* it. To the extent that JS1.7+ is meaningful, I argue we have done so without user confusion. Yes, users wish arrays were iterated by for-in returning values, not keys, but you can say

for (i in values(a))

if you need to be sure. Likewise, if you must have property names,

for (k in keys(o))

for any object o will guarantee keys, not values, and not Fibonacci numbers.

The bottom line is that adding new syntax for custom iteration is missing the forest for the trees, arguing about how one more tree is safer and less confusing. In reality, the forest needs to stay small, and reform efforts can result in users understanding how to harvest the trees that we have, instead of having to understand and make good use of yet more trees.

/be



More information about the es-discuss mailing list