Indeed. Functor.fmap is just a convenience.

The fmap method of Functor is just an shared interface which each type implements â€” so you can imagine an “Fmappable” interface (which I think is what you mean when you say “implement that method on the kind itself” â€” though “kind” there should be “type”).

What you gain by the abstraction is when you write code which works for arbitrary functors. But that would still work with an Fmappable interface.

However, you correctly point out that:

> Surely the real benefit is that the implementation of fmap is now decoupled from the kind, fmap can now be added to any kind, even those you donâ€™t have code for or written without the idea of fmap.

Yes, that’s one of the points of using typeclasses rather than Java-like interfaces. For instance, that’s the difference between Ordering (a typeclass) rather than Ordered (a Java-like interface for the same concept). Another point is that you can have different interfaces for the same type. Yet another point (which is not used here) is that you can instances for, say, F[A] but not F[B], which is sometimes useful. See for instance the paper “Type classes as objects and implicits”, http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf or http://dl.acm.org/citation.cfm?id=1869489.

]]>