G'day all.
Quoting Derek Elkins
Of course, this is a concrete example using basic ideas of programming and not some "intuitive analogy". I feel comfortable working with adjunctions, but I don't have some general analogy that I use.
I think this is important. The concept of an adjunction isn't like that of a natural transformation. In Haskell, natural transformations are functions that respect the structure of functors. Since you can't avoid respecting the structure of functors (the language won't let you do otherwise), you get natural transformations for free. (Free as in theorems, not free as in beer.) Adjunctions, on the other hand, you have to make yourself. As such, they're more like monads. I use at least three distinct pictures when I'm working with monads: - Overloaded semicolon. - Functorial container (e.g. lists). - Term substitution system. ...but even that doesn't fully cover all the possibilities that monads give you. Monads are what they are, and you use them when it seems to make sense to implement the Monad interface for them. It's sometimes only obvious that an interface is conformed to after the event. For example, consider Data.Supply: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply-0.1 It's clear in retrospect that Supply is a comonad, but probably neither the paper authors nor the package author, smart as they are, noticed this at the time of writing, because you need experience with comonads to identify them. I think it's the same with adjunctions. Having said that, I think it makes sense to come up with some example pictures, much like the example pictures of monads that people use. Looking at those examples again: phi :: (F a -> b) -> (a -> U b) phiInv :: (a -> U b) -> (F a -> b) One thing that springs to mind is that an adjunction could connect monads and their associated comonads. Is that a good picture? Cheers, Andrew Bromage