RxScala: Let's add Monad and Applicative instance

[everpeace]

Hi folks,

As I showed in my repo everpeace/observable-canbe-monad, Observable can be monad(List like) and applicative functor(ZipList like).

As functional programming community proved, monadic computation gives us really powerful syntax for composing, transforming them. I know Observable already provides many useful combinators. However, providing monad/applicative instance could provide more powerful and intuitive syntax about composing/transforming Observable to users like below. And, some useful operators provided by scalaz can be used (e.g. ^ operator).

// The case evaluated as List like monad
// this is equivalent with Observable(3,4,6,8)
for { v <- Observable(1,2);
      w <- Observable(3,4)} yield v*w  
=== ^(Observable(1,2),Observable(3,4)){_*_}

// The case evaluated as ZipList like applicative
// this is equivalent with Observable(3,8)
for { v <- Observable(1,2);
      w <- Observable(3,4)} yield v*w  
=== ^(Observable(1,2),Observable(3,4)){_*_}

Then, I would be happy if I could hear opinions from RxScala contributors.

• Would it be really useful if RxScala includes some functional typeclass instances?
• If so, what is the best way to contribute?? I think it would be better that we introduce
  • rx.lang.scala.scalaz package in language-adaptors/rxjava-scala, or
  • new contrib project like rxjava-scalaz in rxjava-contrib directory.

[zsxwing]

I also find foreach is missing.

/cc @headinthebox @samuelgruetter

[everpeace]

@zsxwing Yeah, Thanks for pointing out what is missing.
I recognize that some type class instances are missing, for example, traversable, foldable, and so on. I am pleased to contribute these instances as well.

Let's list them!

[samuelgruetter]

Regarding foreach: It is blocking, so it's not in Observable, but in BlockingObservable. Theoretically, it would also be possible to make a non-blocking foreach, but in C# and Java, it's blocking, and I think it wouldn't be a good idea to change the semantics.
And @everpeace your contributions are welcome, just make sure that the main rxjava-scala package has no dependency on scalaz.

[everpeace]

@samuelgruetter Thanks for pointing out semantic gap issue. I agree with your opinion. I will add type class instances which preserve Observable's semantics.

So, which is better do you think?? May I add a dependency to scalaz to rxjava-scala? Or, another project in rxjava-contrib is better?

[headinthebox]

I'd say do another project, the goal is to try tokeepthe core of Rx (all flavored) lean and mean, and let people to chose if they want additional stuff.and no depend cries on Scalaz. KISS.

[everpeace]

@headinthebox
Thanks for leading a direction I should follow. OK. I will create a project, 'rx-scalaz' or something, in rxjava-contrib folder. I will take a week off in the next week. So, I will make PR around the end of this month.

Thanks!