Day 2 meeting notes

[Maciej Stachowiak]

On Jul 30, 2010, at 2:53 PM, Brendan Eich wrote:

> On Jul 30, 2010, at 2:43 PM, felix wrote:
> 
>>> Of course this does not say what the syntax for a meta-programmable
>>> iteration construct should be, but laziness suggests "all" is not
>>> precisely on target.
>> 
>> so why not make it "for each"?  for-each iterates over a stream, and in the case of arrays the stream is the array values.
> 
> Reasons not to add each:
> 
> 1. Avoid another contextual keyword (few implemented E4X).
> 2. Avoid confusion over what "each" means.
> 3. Even assuming we added "each" based on E4X, the objection that |for each (x in y)| loops would need to cope with y being a proxy that customizes value-iteration exists.
> 
> Point 3 is Waldemar's objection w.r.t. |for-in| becoming customizable (as it is in JS1.7 and Python). It applies equally to |for-each-in| given the E4X precedent of non-proxy object on right of 'in' being enumerated (iterated over its enumerable keys), and its enumerable keys' values returned.
> 
> One can bikeshed for days on all sorts of vague and wrongly general words such as "each". Instead, focusing on the right side of "in", providing an explicit iterator-factory call, seems strictly better.

I think that while "for each ... in" or "for all ... in" is a potentially confusing distinction vs. "for ... in", it still seems less potentially confusing to me than having no distinction at all.

Another entry for the bikeshedding pile: "for values ... in". That definitely screams "values, not keys".

Regards,
Maciej