concept functor in category functional programming

This is an excerpt from Manning's book Functional Programming with Kotlin MEAP V07. Login to get full access to this book.

Answer, to your own satisfaction, the question of why it’s not possible for Foldable to extend Functor. Can you think of a Foldable that isn’t a functor?

This is because foldRight, foldLeft, and foldMap don’t give us any way of constructing a value of the foldable type. In order to map over a structure, you need the ability to create a new structure (such as Nil and Cons in the case of a List). Traversable is able to extend Functor precisely because a traversal preserves the original structure. Here’s an example of a Foldable that is not a functor:

This is an excerpt from Manning's book Functional Programming in C++. Login to get full access to this book.

Classes with the overloaded call operator are often called functors. This term is highly problematic because it’s already used for something different in category theory. Although we could ignore this fact, category theory is important for functional programming (and programming in general), so I’ll keep calling them function objects.

I’m going to break a bit from the usual form of this book: instead of starting with an example, I’ll start by defining a concept and then explore the examples. We’re going to begin with a functor. As I mentioned in chapter 3, many C++ developers use this word to mean a class with the call operator, but this is a misnomer. When we talk about functors in FP, we’re talking about something quite different.

A functor is a concept from an abstract branch of mathematics called category theory, and its formal definition sounds as abstract as the theory it comes from. We’ll define it in a way that should be more intuitive to C++ developers.

Figure 10.1 A functor is a class template over a type T. You can lift any function operating on T to work on instances of that class template.

Transforming a functor with one function and then with another is the same as transforming the functor with the composition of those two functions (see figure 10.2):

f | transform(t1) | transform(t2) ==
f | transform([=](auto value) { return t2(t1(value)); })

copy

This is an excerpt from Manning's book Functional Programming in C#: How to write better C# code. Login to get full access to this book.

Why is functor not an interface?

Figure 8.3. Relation of functor, applicative, and monad

This is an excerpt from Manning's book Functional Programming in JavaScript. Login to get full access to this book.

5.2.2. Functors explained

In essence, a functor is nothing more than a data structure that you can map functions over with the purpose of lifting values into a wrapper, modifying them, and then putting them back into a wrapper. It’s a design pattern that defines semantics for how fmap should work. Here’s the general definition of fmap:

fmap :: (A -> B) -> Wrapper(A) -> Wrapper(B)                 #1

copy

The function fmap takes a function (from A -> B) and a functor (wrapped context) Wrapper(A) and returns a new functor Wrapper(B) containing the result of applying said function to the value and closing it once more. Figure 5.3 shows a quick example that uses the increment function as a mapping function from A -> B (except in this case, A and B are the same types).

Figure 5.3. A value of 1 is contained within Wrapper. The functor is called with the wrapper and the increment function, which transforms the value internally and closes it back into a container.

Notice that because fmap basically returns a new copy of the container at each invocation, much as lenses (chapter 2) work, it can be considered immutable. In figure 5.3, mapping the increment over Wrapper(1) returns a completely new object, Wrapper(2). Let’s go over a simple example before you begin applying functors to solve more-practical problems. Consider a simple 2 + 3 = 5 addition using functors. You can curry an add function to create a plus3 function:

This is an excerpt from Manning's book Functional Programming in Scala. Login to get full access to this book.

Whenever we create an abstraction like Functor, we should consider not only what abstract methods it should have, but which laws we expect to hold for the implementations. The laws you stipulate for an abstraction are entirely up to you,^[3] and of course Scala won’t enforce any of these laws. But laws are important for two reasons:

³ Though if you’re going to borrow the name of some existing mathematical abstraction like functor or monoid, we recommend using the laws already specified by mathematics.

This establishes that all applicatives are functors. We implement map in terms of map2 and unit, as we’ve done before for particular data types. The implementation is suggestive of laws for Applicative that we’ll examine later, since we expect this implementation of map to preserve structure as dictated by the Functor laws.

Note that Traverse now extends both Foldable and Functor! Importantly, Foldable itself can’t extend Functor. Even though it’s possible to write map in terms of a fold for most foldable data structures like List, it’s not possible in general.