Recently I've been dusting off my knowledge on how Monads work. I've also been introduced to the concept of a 'Comonad', which is described as the inverse dual of a monad. However, I am impossible to wrap my head around it.

To understand Monads, I made the own analogy for myself:

Monads can be seen as 'a blueprint to build conveyor belts of expressions'.

To define a new Monad(a new kind of conveyor-belt system) you need to define:

  1. A way to put something on a conveyor belt, e.g. 'start' a conveyor belt. (Known as unit or return)
  2. A way to connect a machine (an expression) that will be part of a conveyor belt to a conveyor belt. (Known as join or bind or >>=).

(There is a third operation that takes the current conveyor belt, throws its contents away and starts a new conveyor belt known as >>, but it is used very rarely.)

For the machines and conveyors to work properly together, you will need to make sure that:

  1. If you put something on a conveyor belt and pass it through a machine, the output should be the same as when you pass it through the machine manually. (Left Identity)
  2. If you want to put a conveyor-belt in-between an already existing conveyor belt, you should not end up with a conveyor belt that has a conveyor belt on top, but rather a single, longer conveyor belt. (Right Identity)
  3. It should not matter for the output if you manually use machine A, and then pass the result through the conveyor-connected B-C, or if you use conveyor-connected A-B and then pass the result manually through C. In other words: ((a >>= b) >>= c) should be the same as (a >>= (b >>= c)) (Associativity)

The most simple conveyor-belt would be the one that just takes the input and always continues on to the next expression. This is what a 'pipeline' is.

Another possibility, is to only let it go through the next machine if some condition is met for the value. This means that if at some of the expressions in-between, the value changes to something that is no longer allowed, then the rest of the expressions will be skipped. This is what the 'Maybe' monad does in Haskell.

You can also do other fancy conditional copy/change rules on the values before or after you pass them to a machine. An example: Parsers (Here, if an expression returns a 'failure' result, the value from before the expression is used as output).

Of course the analogy is not perfect, but I hope it gives an okay representation of how monads work.

However, I am having a lot of trouble to turn this analogy on its head to understand Comonads. I know from the small amounts of information I've found on the internet that a Comonad defines:

  • extract, which is sort of the reverse of return, that is, it takes a value out of a Comonad.
  • duplicate, which is sort of the inverse of join, that is, it creates two Comonads from a single one.

But how can a Comonad be instantiated if we're only able to extract from them or duplicate them? And how can they actually be used? I've seen this very amazing project and the talk about it (which I unfortunately understood very little of), but I am not sure what part of the functionality is provided by a Comonad exactly.

What is a Comonad? What are they useful for? How can they be used? Are they edible?

  • 2
    "how can a Comonad be instantiated if we're only able to extract from them or duplicate them?" - I'll answer your question with a question: how can a Monad be consumed if you're only able to lift values into them and sequence computations? – Benjamin Hodgson Jun 16 '16 at 13:29
  • 1
    The "machine at the end of the conveyor belt" (aside: I don't find analogies all that helpful when talking about monads) of the IO monad is the Haskell runtime system, which invokes main. There's also unsafePerformIO, of course. If you want to think of the Maybe monad as having a "machine at the end of the conveyor belt" you can use maybe. – Benjamin Hodgson Jun 16 '16 at 14:00
  • 1
    But, turning your explanation around, when you want to produce a comonadic value at the start of a chain of cobind applications, there must be some function which does something useful with the internal representation of your comonad. – Benjamin Hodgson Jun 16 '16 at 14:01
  • 2
    specific instance of comonad or monad can clearly have more functionality than required just to implement the typeclasses – jk. Jun 16 '16 at 14:13
  • 2
    Not that this is going to be helpful if you don't approach this question from the category-theoretical / mathematical side, but I wanted to point out that a comonad is not the inverse but rather the dual of a monad. – Jörg W Mittag Jun 16 '16 at 16:27

A comonad is, just like a monad, a mathematical structure in category theory. The co-prefix is very common there to denote "inverses" as you put it (although I don't think pure mathematicians agree on the choice of word).

In category theory there are categories, which are briefly put a collection of objects (of any type or nature, the internal structure is irrelevant) and some arrows between these objects. For something to be a category, the arrows must follow some laws (left/right-identity and associativity), but that isn't really important here.

Now, category theory is both very abstract/hard to grok and vast. It takes a lot of time to go through it all (and I haven't studied it formally, I only know some basics), but there is a notion used that is called a dual. Basically, for every category you can construct an opposite category by just doing the same thing but "reversing all the arrows". This is a very naive definition but it's hard to try to summarize. The dual of something in a category C is basically the same thing in the opposite category C_op (getting a headache yet?)

Anyway, if you have a monad over some category (and a category can for instance be a category where the objects are types in some programming language and the arrows are functions between the types), then a comonad is basically the same thing, only you've reversed all the arrows (kind of like reversing the function signatures in this case).

A more "hands-on" description (albeit not SUPER hands-on) can be found in this discussion between Erik Meijer and Brian Beckman where they are discussing the notion of duality and how Erik went about "reversing the arrows" for IEnumerable<T> in C# when creating the reactive framework and IObservable<T> (which as far as I can tell, and I'm happy to be corrected, basically is a list comonad instance).

Another practical example of comonads mentioned in the video is the Task<T> type in .NET, where Task<U> ContinueWith<U>(Func<Task<T>, U>) would be the dual of bind (or SelectMany as it's called in C#)


From my little understanding, a comonad is a Rube Goldberg machine to do post-docs:


...sorry, I couldn't resist it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.