[Haskell-cafe] Functional programmer's intuition for adjunctions?
ajb at spamcop.net
ajb at spamcop.net
Wed Mar 5 20:36:19 EST 2008
Quoting Derek Elkins <derek.a.elkins at gmail.com>:
> 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:
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?
More information about the Haskell-Cafe