Apparently fmap is a useful thing in dealing with monads. Together with join, it allows to define the behaviour of a monad rather than using the pair unit+return. [Unfortunately for fmap and join, I have managed to do well with unit+return so far.]
If there is a function func1 implements F<A,B> you can promote it to a func2 implements F<Monad<A>,Monad<B>>. The latter carries inside itself the capability of doing the following, whenever we put it at work:
- unwrap the A from Monad<A>
- calculate the B as func1(A)
- rewrap it as a new Monad
There is a relevant example given by apocalisp, in which a function length, capable of measuring the length of strings (that’s not what you’d call a tough job to do, but it makes the point), is made exception-safe by creating a fmap(length) which can handle strings coming e.g. from reading a file. The interesting bit is that fmap(length) does not carry any throws FileNotFoundException in the signature, nor any try/catch block in its body.
I can imagine that fmap has something to say also outside the world of monads, but where? I think at a fmap(List<A>), but then I recollect that the Haskell sites say that also List<A> is a monad. Too bad…
In any case fmap looks interesting. Nice to know it exists, maybe one day I will apply it in a real-world problem.