Add Choice type class, closes #463

[adelbertc]

No description provided.

[adelbertc]

Couldn't find any laws associated with it, what are the laws @julien-truffaut ? I may well be bad at looking for laws.

[codecov-io]

Current coverage is 62.75%

Merging #468 into master will increase coverage by +1.85% as of 13b13b6

@@            master    #468   diff @@
======================================
  Files          143     147     +4
  Stmts         1977    2040    +63
  Branches        32      32       
  Methods          0       0       
======================================
+ Hit           1204    1280    +76
  Partial          0       0       
+ Missed         773     760    -13

Review entire Coverage Diff as of 13b13b6

Powered by Codecov. Updated on successful CI builds.

[fthomas]

Laws for Choice can make use of id, compose/andThen, and choice. I tried briefly to write down a law with just those operations, but failed. scalaz has also no laws for Choice. Maybe it is an outlaw and there are only laws in combination with Arrow?

[julien-truffaut]

@adelbertc good point, I have never checked. For sure it must obey all laws of Category but I am not sure what can we say about choice

[julien-truffaut]

in haskell, Choice seems to be part of a stronger class ArrowChoice which depends on Arrow

http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Arrow.html#v:-124--124--124-

[adelbertc]

Hm so do we want to keep Choice lawless and then add an ArrowChoice with laws on top of it? Or toss Choice and just have ArrowChoice?

[fthomas]

If we keep Choice we could just as well have Pure (as in Applicative.pure). The same reasons for rejecting Pure would also apply to Choice, right?

[adelbertc]

Fair point. I'm in favor of nixing Choice and just having ArrowChoice. Is this OK for Monocle @julien-truffaut ?

[julien-truffaut]

I agree, it is better to have a lawful ArrowChoice than a lawless Choice.

I will have to drop Choice instance for Lens and other optics but I can still implement a useful sum so it is not an issue (cf https://github.com/julien-truffaut/Monocle/blob/master/core/src/main/scala/monocle/Lens.scala#L48)

[julien-truffaut]

btw, should we apply the same reasoning to Split? As far as I can see it is a lawless as Choice

[adelbertc]

Closing PR since this has no laws, Lens just won't have a Choice instance. If we end up wanting it again maybe we can put it in alleycats.

Holding off on implementing ArrowChoice until someone finds themselves needing it/can produce an example of use.

[julien-truffaut]

@adelbertc make sense, thanks for starting the discussion on "lawfulness" of Choice, I completely missed it.

Do you think it would make sense to remove Split as well / move it to alleycats ?

[fthomas]

@julien-truffaut Split has laws, see https://github.com/non/cats/blob/82dbf4076572dfbb6e29dd49875f5e5d929f80be/laws/shared/src/main/scala/cats/laws/SplitLaws.scala and https://github.com/non/cats/pull/232

[julien-truffaut]

@fthomas thanks, so it seems that it is because choice does not change the second type parameter that we cannot write any useful law with compose or andThen

[fthomas]

Wait! It seems that I didn't tried hard enough to find a law! How does this look like:

fac: F[A, C]
fbc: F[B, C]
fcd: F[C, D]

choice(fac, fbc) andThen fcd             : F[Xor[A, B], D]
choice(fac andThen fcd, fbc andThen fcd) : F[Xor[A, B], D]

It seems that the types align!

[fthomas]

ChoiceLaws is here: adelbertc#3

[fthomas]

adelbertc#3 has now ChoiceLaws, ChoiceTests and verifies that Function1 and Kleisli satisfy the above law.

Ok, now we have a law that relates choice to andThen/compose which justifies that Choice is a subtype of Compose. But how do we justify that Choice is a subtype of Category (which has id)? I think we need another law that relates choice to id.