Add Applicative and Functor as superclasses of Monad

[ejconlon]

The choice of Applicative methods is probably the most controversial part of this PR (if it is at all).

I think I maintain source compatibility for everything Monad.scala.

[ejconlon]

Not sure why CI failed. "./sbt test" passes for me locally.

[ianoc]

CI looks green to me?

[ejconlon]

Yeah it re-ran for some reason. Some tests marked as flaky? Green now.

[jcoveney]

the explanation of the difference in failure modes between sequence and join is not clear in this comment, imo

[ejconlon]

Hmm... What I'm trying to say is that join and sequence are good primitives for functors that model concurrent computations. (You could do everything with flatMap but you potentially waste time waiting on operations in order. With join/sequence, if one of them fails, you can fail the entire thing right away.) I can take that part out.

[jcoveney]

I think the comment is important, I just found the wording a little muddled.

[ejconlon]

Better? I'm trying to give a simple and concrete motivation as to why one would care about this typeclass.

/**

• Simple implementation of an Applicative type-class.
• There are many choices for the canonical second operation (join, sequence, joinWith, ap),
• all equivalent. For a functor modelling concurrent computations with failure, like Future,
• combining results with join can save a lot of time vs flatMap. (Given two operations, if the second fails before
• the first completes, one can fail the entire computation right then. If one used flatMap,
• one would have to wait for the first operation to complete before failing it.)
  */

[jcoveney]

This is much clearer. Thank you!

[jcoveney]

Looks good to me. Unless you have strong feelings to keep genSequence I'd punt on it, let's get the tests green and then I'll give it a once over (or oscar can) and it looks good to merge.

[ejconlon]

Ok, removing genSequence. It just makes subclassing harder.

(I'm finding the CI to be pretty flaky, failing on different unrelated tests. This branch has been passing locally for me the whole time...)

[jcoveney]

If we need to add it back we can

And yeah, travis has been acting up recently... very frustrating. I think it might be resource starved.

[ejconlon]

Ping (ignore the CI flakiness)

[jcoveney]

@johnynek , I'm happy with this patch, though you didn't like the naming of join vs. zip. Thoughts?

[Gabriella439]

I think this use of the word join is better than the one in Haskell, but zip is also excellent, too, and probably less controversial.

[ejconlon]

Ping?

[Gabriella439]

Actually, I think join is probably better than zip, just because we have precedent for this at Twitter. We have Future.join and Stitch.join already.

[jcoveney]

Thanks! Now let's use it :D

[johnynek]

Well, I tend to bias towards the standard, and I hope Twitter Futures can extends Scala futures one day, and scala futures use zip.

Anyway. I guess this is an area of inconsistence, since the scalding Execution monad uses zip as join (and cross on TypedPipe, though I'm not sure what applicative functions will be useful for TypedPipe).