Brendan Eich (2014-10-06T17:17:40.000Z)
Domenic Denicola wrote:
>> >  Note the this.clone() call. This is novel, and required to avoid exhausting the receiver iterator.
>
> This is noteworthy and worth keeping in mind regardless of the rest of the discussion. I think I would be fine having %IterablePrototype%.map exhaust the iterator. I would `.clone()` manually myself if I didn't want that. But in general anytime I loop through the iterator---either directly with `for`-`of`, or indirectly with `.map` and friends---I would expect exhaustion.

For iteration, sure. For map or other functional (pure?!) APIs? Yikes.

If in ES7 we build up the duality between iterables and observables, add 
for-on, pave the way toward FRP, then `map` as a protocol (part) should 
be pure with respect to its receiver, ISTM.

>> >  We could just use FP-style map, filter, etc. APIs, but as argued among TC39ers, OOP wins in JS: (a) it matches built-ins; (b) it composes left to right, not inside out.
>
> I am still hoping [the bind operator][1] gives us a good middle ground. E.g.
>
> ```js
> import { map } from "js/iterables";
>
> var newMap = oldMap::map(([k, v]) =>  [k+ 1,  v+ 1]);
> ```
>
> Here I guess `map` would look something like
>
> ```js
> function map(...args) {
>    return new this.constructor(this.entries().map(...args));
> }
> ```
>
> (Note that I use `new this.constructor(entriesIterable)` instead of your `var m = new this.constructor()` plus `m.set(...)`. Unclear which is better.)

More elaborate constructor protocol, but if it's part of maplike, may be ok.

> [1]:http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator

Problem is :: vs. just dot, and now you have two problems. I'm actually 
good with FP inside-out, could learn to love :: if we add it, but the 
main objection IMHO is two-problems. OOP means just dot.

>> >  Comments welcome.
>
> My first thought is that it seems a little far out there given that we're talking about the net benefit being reducing
>
> ```js
> var newMap = new Map(oldMap.entries().map((([k, v]) =>  [k+ 1,  v+ 1]);
> ```
>
> to
>
> ```js
> var newMap = oldMap.map(([k, v]) =>  [k+ 1,  v+ 1]);
> ```

Fair, just trying to develop a thought on es-discuss. I'm not sure we 
should do anything in TC39 about this. I want future underscore.js 
libraries to tread those cowpaths we ultimately pave.

Also the ES7 iterable/observable duality and the DOM maplike demands 
combine to push for paving sooner. We should be minimalists as you 
suggest, though.

> My second thought is that we might also want to consider approaching this from the perspective of traits, see e.g. [an earlier discussion about Set][2].

Traits are great -- we lost a live, championed proposal at some point on 
the road to ES6. Who will revive?

/be
forbes at lindesay.co.uk (2016-02-01T14:24:26.258Z)
> I would expect exhaustion.

For iteration, sure. For map or other functional (pure?!) APIs? Yikes.

If in ES7 we build up the duality between iterables and observables, add 
for-on, pave the way toward FRP, then `map` as a protocol (part) should 
be pure with respect to its receiver, ISTM.

> the bind operator

More elaborate constructor protocol, but if it's part of maplike, may be ok.

Problem is :: vs. just dot, and now you have two problems. I'm actually 
good with FP inside-out, could learn to love :: if we add it, but the 
main objection IMHO is two-problems. OOP means just dot.

> My first thought is that it seems a little far out there

Fair, just trying to develop a thought on es-discuss. I'm not sure we 
should do anything in TC39 about this. I want future underscore.js 
libraries to tread those cowpaths we ultimately pave.

Also the ES7 iterable/observable duality and the DOM maplike demands 
combine to push for paving sooner. We should be minimalists as you 
suggest, though.

> My second thought is that we might also want to consider approaching this from the perspective of traits

Traits are great -- we lost a live, championed proposal at some point on 
the road to ES6. Who will revive?