-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Justify Bimonad #30
Comments
I agree that unless we can find additional laws and/or derived operations then I'm hoping to get law-checking implemented today, so I'll look at adding this requirement. |
I say kill the Bimonad |
Please le me know before you kill it as it's the only thing I've used in porting banana-rdf to Cats!! Typical old use case: import scalaz._
import scalaz.syntax._, monad._, comonad._
abstract class SerialisationTestSuite[Rdf <: RDF, M[+_] : Monad : Comonad, Sin, Sout]( ......
// both Monad and Comonad are Functors, so they compete for the
// syntax. So we choose arbitrarily one of them.
// TODO @betehess to ask scalaz people
val M = Monad[M]
import M.functorSyntax._
.....
val graph = reader.read(new StringReader(soutString), rdfCore).copoint And new version: import cats.Bimonad
import cats.implicits._
abstract class SerialisationTestSuite[Rdf <: RDF, M[+_] : Bimonad, Sin, Sout]( ....
val graph = reader.read(new StringReader(soutString), rdfCore).extract Perhaps independent of your decision, the general look'n'feel of the new is much nicer, including For the full picture, the default M we have is a import scalaz.{ Monad, Comonad }
import scala.util.Try
object tryInstances {
implicit final val TryInstance = new Monad[Try] with Comonad[Try] {
def point[A](a: => A): Try[A] = Try(a)
def bind[A, B](fa: Try[A])(f: A => Try[B]): Try[B] = fa flatMap f
override def map[A, B](fa: Try[A])(f: A => B): Try[B] = fa map f
def cobind[A, B](fa: Try[A])(f: Try[A] => B): Try[B] = Try(f(fa))
override def cojoin[A](a: Try[A]): Try[Try[A]] = Try(a)
def copoint[A](p: Try[A]): A = p.get
}
} New: import cats.Bimonad
import scala.util.Try
object tryInstances {
implicit final val TryInstance = new Bimonad[Try] {
def pure[A](a: A): Try[A] = Try(a)
def flatMap[A, B](fa: Try[A])(f: A => Try[B]): Try[B] = fa flatMap f
override def map[A, B](fa: Try[A])(f: A => B): Try[B] = fa map f
def coflatMap[A, B](fa: Try[A])(f: Try[A] => B): Try[B] = Try(f(fa))
def extract[A](p: Try[A]): A = p.get
}
} |
FYI... I've changed banana-rdf to use |
I'd push back by saying that something can be interesting and useful without being mathematically interesting (or useful). |
Well, in terms of being useful, Bimonad is much more user friendly Bimod version: import cats.Bimonad
import cats.implicits._
abstract class SerialisationTestSuite[Rdf <: RDF, M[+_] : Bimonad, Sin, Sout]( ....
val graph = reader.read(new StringReader(soutString), rdfCore).extract
new : import cats.{Applicative, Comonad, Monad}
import cats.implicits._
abstract class SerialisationTestSuite[Rdf <: RDF, M[+_] : Monad : Comonad, Sin, Sout]( ......
// both Monad and Comonad are Functors, so they compete for the syntax......
// Luckily I had this comment, so I found it quite easy to work out what to do
import Applicative.ops._
....
val graph = reader.read(new StringReader(soutString), rdfCore).copoint
Plus the |
Let me play devil's advocate. If we have |
The reason for wanting |
I've changed my mind, I . I'm voting for it to stay in. now :) |
Should we formulate laws for |
@fthomas it turns out I had a branch with exactly this law sitting around. I'll push a PR now. |
@non, great, thanks! Another "problem" I've with |
Agreed that the clash of meaning on |
https://github.com/non/cats/pull/511 I am fine with changing the name -- it seems like a good idea. |
Since a comonad is the categorical dual of a monad, self-dual seems to be an appropriate term. Btw: Now that we have laws for |
@fthomas would you be OK with shortening it to |
BTW https://hackage.haskell.org/package/comonad-4.2.7.2/docs/Control-Comonad.html#t:ComonadApply
I think |
Disclaimer: I've never, ever had a naming suggestion taken up. DualedMonad - ie an XZY that has been Dualed with itself: From Google:
|
I am fine with |
👍 |
Per a conversation with Kmett that I only understood about 10% of (i.e., better than usual) the notion of
Bimonad
is interesting only if theMonad
andComonad
instances are each others' co-algebras, otherwise we can't say anything interesting. It's also not clear whether these things we can say lead to useful derived operations. So I suggest removingBimonad
unless we can state its law and identify operations that it provides; closing the diamond is fun but not reason enough.The text was updated successfully, but these errors were encountered: