|
![](/i/fill.gif) |
Darren New wrote:
> You should do the same diagram and label things with what they're used for.
>
> "Things that translate functions to other functions"
> "Things that hold one of several other types"
> "Things you can iterate over"
>
> Stuff like that.
You could say "Functor is any container that has a 'map' function".
Given this definition, it is no surprise that lists, trees, arrays, sets
and so on are all functors. But in addition, I/O operations, STM
transactions and regular functions are *also* functors - despite the
fact that these things look nothing like "containers".
The Functor class defines one method: fmap. It's exactly like the normal
"map" function, but it works on any Functor, not just lists. Given a
function f that converts integers into characters, fmap f would turn a
list of integers into a list of characters. Or an array of integers into
an array of characters. Or a set. Or a tree. Or whatever.
But fmap f can *also* turn an I/O operation that returns an integer into
an I/O operation that returns a character. (Same goes for an STM
transaction, a regular function, or anything else that "returns" data.)
That's the trouble; many of these classes are so damned general that
it's hard to come up with a metaphore that encompasses all of them.
Having just said that, some of them are easier than others. Monoid is
fairly easy (provided you don't try to explain the mathematical
formalism of "associative operation"). Once you grok that a container
isn't necessarily a *container*, Functor, Pointed and Applicative are
fairly easy. Arrow isn't too bad. Monad is a simple idea that's hard to
explain. Foldable is simple in principle, and Traversable just makes no
****ing sense at all...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |