These are chat archives for typelevel/cats

28th
Apr 2018
Olivier Mélois
@Baccata
Apr 28 06:45

Hi people. Say I'm implementing a Monad for an F[_], but want to override the ap so that my F[_] retains some parallel behaviour (for instance, using Matryoshka's hyloM to perform some validation whilst building a tree). Am I utterly wrong ? I know that Monad has laws, Applicative has laws, but is there a formal law that says "thou shall never override" ?

(I'm asking because the library I need to feed a monad does provide an alternative method asking for a Parallel)

Piotr Gawryś
@Avasil
Apr 28 06:50
@Baccata you can override whatever you want as long as it passes the laws :) It's being done all the time whenever your data type can provide more efficient implementation
P. Oscar Boykin
@johnynek
Apr 28 06:51
@Baccata there is a law that ap is the same as you would get from pure and flatMap semantically. But it may be possible to optimize in some cases while keep semantic equivalence.
Olivier Mélois
@Baccata
Apr 28 06:55
Okay, that's helpful :smile: . @johnynek Is that law implemented somewhere ?
P. Oscar Boykin
@johnynek
Apr 28 06:56
Yes. In cats test for MonadLaws. I’m on the phone but you should be able to find it.
Piotr Gawryś
@Avasil
Apr 28 06:57
You can actualy use cats-laws module to add those laws to your test suites
Olivier Mélois
@Baccata
Apr 28 07:04
@Avasil mmm I guess I see. Because map is implemented using flatMap, override ap could break the Applicative laws
Is that why no Monad implementation is provided for Validated ?
Piotr Gawryś
@Avasil
Apr 28 07:54
I think so, with Monad you sequence effects and fail early but with just Applicative you can evaluate effects independently and that's what you want for Validated
Fabio Labella
@SystemFw
Apr 28 09:02
@Baccata Monad can't be implemented for Validated because you cannot have a monad instance that accumulates errors (try writing one to see what I mean!), you can only short circuit, which would make ap and flatMap behave differently
Olivier Mélois
@Baccata
Apr 28 21:50
@SystemFw yeah that's pretty obvious. My question had more to do with why ap and flatMap behaving differently is bad I guess.
Fabio Labella
@SystemFw
Apr 28 21:50
right
it's simply to allow refactors like this to be safe
for {
 a <- fa
 b <- fb
} yield f(a, b)
into
(fa, fb).mapN(f)
Olivier Mélois
@Baccata
Apr 28 21:52
oh
right
thanks, that's the best explanation I've read about it ^^
Luka Jacobowitz
@LukaJCB
Apr 28 21:54
And that’s even more important if you have some generic code that’s parametrized on F[_]: Monad and you decide you no longer need Monad and simply change it to Applicative, that’d change behaviour even though your code looks the same
Fabio Labella
@SystemFw
Apr 28 21:57
@LukaJCB no, that can happen anyway :)
Applicative on its own cannot enforce ordering of effects, you need a Monad constraints for that. But if you do have such a constraint, then Applicative ops are guaranteed to be consistent with the Monadic ones