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