Explain that again?
ie: say I have some value `f` that is a functor. If I call `map identity f` I should always get back `f`. The mere existence of a `map` function doesn't imply this law holds.
The identity function always returns it's argument unmodified. (identity x = x)
(Now, in Haskell the type system does not encode that law, but not following it would be breaking the interface.)
If this explanation doesn't make sense or you need more examples I'm happy to expand
EDIT: Both me and grandparent forgot another law for functors. They also need to preserve composition.
fmap (f . g) == fmap f . fmap g
In english, if I combine the functions f and g and map them, it should be the same as if I first map g and then map f
I didn't state this because this generally comes for free, assuming no shenanigans such as runtime type reflection/type-casing (but in that case all laws go out the window). In particular in Haskell (which is what I assume you're coming from given fmap and your ML-ish syntax) this is a superfluous law. If a type constructor's `fmap` obeys the identity law, it must obey the composition law.
This sentence just taught me more about functional programming terminology than 4 years of university and 20 years of casual blog-post reading :O
> fmap (f . g) == fmap f . fmap g
Can you give an example where that doesn't follow from `map identity f == f`? Assuming of course `f` .. is what I think is called 'pure'? i.e. is deterministic on its input arguments.
For example, caches whose eviction calculation is triggered by function invocation aren't functors, even if you can map over the elements in the cache (since just calling any function on the cache can cause certain elements to be evicted). That's a bit of a weird one because caches also usually have some time-dependent behavior (which in general makes notions of things like equality a bit hard to pin down and so moots a lot of laws), but you can also have caches with eviction policies that are not based on time strictly, but rather deterministic heuristics that use the number of function calls as an input to the heuristic.
Another example is certain tree-based data structures that use function calls to rebalance themselves in a way where the rebalancing causes publicly observable changes. Again there just calling map by itself can trigger a rebalancing, regardless of whether identity is passed or not.
Another example is stuff like variants of `Iterator` where just iterating over something creates changes or function calls are logged.
FWIW all these cases of a mappable non-functor can be changed into a mappable functor, simply by "suspending" calling the function until you actually ask for a value (so the `map` call does nothing other than just squirrel the function away somewhere). So often the idea of a mappable non-functor isn't useful so much for truly distinguishing a functor from a non-functor, as it is for pointing out how you should implement `map` in a way that "makes sense."
For example, ruby's hash "map" returns an array instead of hash. That's not really a map, is it?
Making this useless distinction between "things with map function" and "functors" serves no purpose. It should be "things with real/fake map functions".
The name of the function does not matter!
interface Mappable<A> {
// Interfaces don't quite cut it here, because you want
// `map` to return a specific implementation of
// Mappable, not a general Mappable, but we'll let that
// slide for the purposes of exposition
map<B>(f: A => B): Mappable<B>
}
class MyWeirdMappable<A>(val myCounter: Int, val myValue: A) implements Mappable<A> {
// Notice the return type is MyWeirdMappable not
// Mappable, as mentioned earlier
map<B>(f: A => B): MyWeirdMappable<B> {
if (myCounter == 0) {
return this
} else {
return MyWeirdMappable(myCounter + 1, f(myValue))
}
}
}
No, although a pure unary function could be viewed as a functor, the other direction doesn't hold.
The common FP definition of a functor is anything that supports a notion of `map` (subject to the restriction that `map`ping the identity function does nothing, this is why a Functor is slightly more than just a Mappable). This is not a unary function although map takes a unary function as an argument.
The more general mathematical definition is a mapping between categories. Categories are sufficiently general that you can view almost anything as a category, which is why a unary function can be thought of as a functor (because a functor can be a mapping between categories that happen to be sets).
But a functor is both more general than a unary function and, in a certain sense, preserves more structure than a function, since it must preserve the structure of the underlying categories whereas functions generally only care about sets.