11

While musing what more useful standard class to suggest to this one

class Coordinate c where
  createCoordinate :: x -> y -> c x y
  getFirst :: c x y -> x
  getSecond :: c x y -> y
  addCoordinates :: (Num x, Num y) => c x y -> c x y -> c x y

it occured me that instead of something VectorSpace-y or R2, a rather more general beast might lurk here: a Type -> Type -> Type whose two contained types can both be extracted. Hm, perhaps they can be extracted?

Turns out neither the comonad nor bifunctors package contains something called Bicomonad. Question is, would such a class even make sense, category-theoretically? Unlike Bimonad (which also isn't defined, and I couldn't really see how might look), a naïve definition seems plausible:

class Bifunctor c => Bicomonad c where
  fst :: c x y -> x
  snd :: c x y -> y
  bidup :: c x y -> c (c x y) (c x y)

probably with the laws

fst . bidup ≡ id
snd . bidup ≡ id
bimap fst snd . bidup ≡ id
bimap bidup bidup . bidup ≡ bidup . bidup

but I find it disquieting that both fields of the result of bidup contain the same type, and there are quite a number of other, perhaps “better” conceivable signatures.

Any thoughts?

Community
  • 1
  • 1
leftaroundabout
  • 117,950
  • 5
  • 174
  • 319
  • 2
    Not an answer, but: A (co)monad is just a (co)monoid (with functor composition as the tensor product) in the category of **endo**functors, right? Haskell bifunctors aren't endofunctors. So I'm not sure what a real bi(co)monad would look like, or even if it makes sense to build such a thing on top of bifunctors. But perhaps there's still something useful that looks "kinda like" a bicomonad, so it's still an interesting question. – Benjamin Hodgson Nov 28 '16 at 10:41
  • Also not an answer, but I come from the math side. For us, a bimonad is a a comonoidal monad, i.e. it is a monad on a monoidal category whose category of modules is again monoidal category. (Recall that modules over an algebra form a monoidal category iff the algebra is a bialgebra). Likewise, a bicomonad is a monoidal comonad. – Jo Mo Oct 29 '19 at 10:52
  • @JoBe very interesting! Could you elaborate that as an answer in math notation? – leftaroundabout Oct 29 '19 at 11:08

1 Answers1

1

This is not an answer, but for Bimonad, how about this?

class Biapplicative p => Bimonad p where
  (>>==) :: p a b -> (a -> b -> p c d) -> p c d

biap :: Bimonad p => p (a -> b) (c -> d) -> p a c -> p b d
biap p q = p >>== \ab cd -> q >>== \a c -> bipure (ab a) (cd c)

instance Bimonad (,) where
  (a,b) >>== f = f a b

I don't know if this is categorically right/interesting, or even remotely useful, but it smells right from a Haskell perspective. Does it match your Bicomonad or something similar?

dfeuer
  • 48,079
  • 5
  • 63
  • 167
  • 2
    Not sure; this looks a lot like the ordinary `Monad` restricted to tuple arguments (which are then curried). – leftaroundabout Nov 28 '16 at 00:53
  • @leftaroundabout Agreed. I do wonder, though, if/how your bicomonad differs from a comonad restricted to tuple arguments. – chi Nov 28 '16 at 01:10
  • @leftaroundabout, isn't that almost true of `Biapplicative` as well (if you exclude boring functors like `Const`)? – dfeuer Nov 28 '16 at 01:50
  • @dfeuer, I consider `Const` one of the more important applicatives, if you're in the business of composing them which is what applicatives are good at. Just sayin... – luqui Nov 28 '16 at 12:22