Trucchi: Dekok: robdubya would know, all I know about it is what he’s told me, since he’s tangentially involved with it, I believe or at least he’ll be writing the docs

Trucchi: What *I* want is a hybrid of CSP channels and observables

Trucchi: IE, channels are valid Observables and implement both Observable methods and a few convenience functions, but can also be used purely as CSP channels

Lillian: Dekok yeah, its much more modular

Pully: 50% of the bulk in current Rx is the 11ty operators

Fuquay: Https://github.com/ReactiveX/RxJS – “RxNext”

Trucchi: I haven’t decided whether I want to do this myself or try and convince the js-csp folks to go that route

Trucchi: Since Observables will eventually be native, IMO it makes sense to make CSP channels compatible with that protocol

Outler: Its pretty fun tracking the es7 proposal. somebody suggested “Observerator” the other day since the semantics of iterable/iterator observable/_____ are a bit wonky

Trucchi: Observables are already sorta the not-necessarily-synchronous ****og to iterators

Donlan: Https://github.com/zenparsing/es-observable/issues/55#issuecomment-138759185

Trucchi: It makes sense to have async generators produce them

Handon: Dekok: what if I have a var that needs to be shared among commands? Do I add a callback to toCommand?

Trucchi: Robdubya: oh that clarifies it a bit

Trucchi: Robdubya: though it misses the fact that iterators are Iterable along the same lines that observables are Observable

Trucchi: An iterator has a Symbol.iterator method that returns itself

Trucchi: Oh, I see Straight has already beaten me to it on that line of reasoning

Trucchi: I like that idea – change Rx “Observers” to “Subscribers” so an observer can be ****ogous to an iterator

Coda: Quite weird that the spec defines filter instead of flatmap though :/

Santopietro: Its Subscriber in RxNext jaawerth

Trucchi: Dekok: what do you mean “instead of”? They’re two different things

Trucchi: Since RxNext may well end up DEFINING the spec I guess I should try and participate

Opeka: Trucchi: flatmap is a more fundamental operation. You could derive both .map and .filter from it

Dorval: So it would make more sense as a minimal spec

Trucchi: Dekok: I agree that if you were to pick between the two, you’d start with flatMap. I’m just saying, why not have both?

Trucchi: Dekok: though wouldn’t it be better to define flatMap in terms of map rather than the other way around?

Dockham: Https://www.youtube.com/watch?v=vgk-lA12FBk

Mittelman: Wait you derive map from flatmap?

Lapek: Then filter is just: Observable.prototype.filter = functionf{ return this.flatmapfunctionx{ return fx? this.ofx : this.empty } }, and map is just Observable.prototype.filter = functionf{ return this.flatmapfunctionx{ return this.offx } }

Freedle: Trucchi: you can have both, but if they’re aiming for a minimal API, then it’s weird to choose .filter, but not have .flatmap

Trucchi: But I’d say a minimal API SHOULD have both

Trucchi: Since they’re both core higher order array methods

Gawrych: Rxnext just defines an Observable, with no operators

Trucchi: I’d also sooner define reduce, then describe them all in terms of reduce

Mcgahen: For URD, I just made every collection type implement a Monad and a Foldable, and then derived all common operations filter, map, sum, every, find, etc from those.

Nuanes: So objects just needed to inherit from the Iterable trait. And if they wanted more performance, just overwrite the methods

Dedinas: I wonder if there was a perf hit. not sure really

Vensel: Higuchi: in this particular usage, Foldable = something that implements reduceRight

Trucchi: Robdubya: perf hit on what? flatmap?

Trucchi: That’s no reason not to have it though!