What would be the methods of a bi-comonad?

Question

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?

Answer 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?