2013/7/17 Claus Reinke <claus.reinke at talk21.com>

>
>  For the specific case of forEach et al
>>>
>> What do you mean by "et al"? I don't believe .map, .reduce or .filter are
>> any interesting to use alongside generators.
>>
>
> And why not? Because yield is a statement, and because those
> operations have not been (cannot be) extended to work with
> generators. Why shouldn't I be able to traverse an array, using the
> ES5 standard operations for doing so, yielding intermediate results
> from the traversal (recall also that yield can return data sent in via
> .next, for incorporation into such traversals)?

I think that considering map, filter or reduce (especially reduce!) as
traversal mechanism is a misuse of these methods.
This is pretty much why find/findIndex has been added (every/some were
"misused" as traversal mechanism with early ending to achieve what
find/findIndex do).



>  Even if so, for..of can work too and is decently elegant (YMMV):
>>
>>     function* g(){
>>         [1,2,3].map(x => {yield transform(x)})
>>     }
>>
>
> I fell for this, too:-) arrow functions have no generator equivalents.

... oops, yeah sorry. So happy to use arrow function that I went out of my
way :-)



>
>  becomes
>>
>>     function* g(){
>>         for(x of [1,2,3]) yield transform(x);
>>     }
>>
>
> Methods can be replaced by built-ins. It is the reverse that
> is now broken.
>


Maybe a solution would be that Array.prototype.map returns a generator when
passed a generator as argument? The result generator would generate the new
values. Could work with filter too (generate only filtered elements).
reduce could empty out the generator to build the value.

  function* filterG(e){ yield e %2 === 0 }
  function* mapG(e){ yield e *e }
  function* reduceG(acc, e){ yield acc + e }

  myArray.filter(filterG).map(mapG).reduce(reduceG)

hmm... my code doesn't work because generators don't have a .map and
.reduce methods. Maybe we can invent ArrayGenerators? which would be a
generator and have Array.prototype someowhere in its prototype chain (array
methods would output an ArrayGenerator if provided either a generator or an
ArrayGenerator)?

Interestingly, "myArray.filter(filterG).map(mapG)" could be sort-of a lazy
value. Actual computation filterG and mapG happens only when generating
values from the
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130717/14817d4f/attachment.html>

2013/7/17 Claus Reinke <claus.reinke at talk21.com>
>> What do you mean by "et al"? I don't believe .map, .reduce or .filter are
>> any interesting to use alongside generators.
>
> And why not? Because yield is a statement, and because those
> operations have not been (cannot be) extended to work with
> generators. Why shouldn't I be able to traverse an array, using the
> ES5 standard operations for doing so, yielding intermediate results
> from the traversal (recall also that yield can return data sent in via
> .next, for incorporation into such traversals)?

I think that considering map, filter or reduce (especially reduce!) as
traversal mechanism is a misuse of these methods.
This is pretty much why find/findIndex has been added (every/some were
"misused" as traversal mechanism with early ending to achieve what
find/findIndex do).

> I fell for this, too:-) arrow functions have no generator equivalents.

... oops, yeah sorry. So happy to use arrow function that I went out of my
way :-)

> Methods can be replaced by built-ins. It is the reverse that
> is now broken.

Maybe a solution would be that Array.prototype.map returns a generator when
passed a generator as argument? The result generator would generate the new
values. Could work with filter too (generate only filtered elements).
reduce could empty out the generator to build the value.

```js
function* filterG(e){ yield e %2 === 0 }
function* mapG(e){ yield e *e }
function* reduceG(acc, e){ yield acc + e }

myArray.filter(filterG).map(mapG).reduce(reduceG)
```

hmm... my code doesn't work because generators don't have a .map and
.reduce methods. Maybe we can invent ArrayGenerators? which would be a
generator and have Array.prototype someowhere in its prototype chain (array
methods would output an ArrayGenerator if provided either a generator or an
ArrayGenerator)?

Interestingly, `myArray.filter(filterG).map(mapG)` could be sort-of a lazy
value. Actual computation filterG and mapG happens only when generating
values from the