# Functors

A functor is a stand-in for a runtime value. In the same way that a variable’s symbol `myNum`

is distinct from its runtime value, (say, `5`

) a functor `myNumFn`

is distinct from its runtime value. In the same way that I can write code using a symbol in Javascript to increment a numerical value at runtime,

`const nextNum = myNum + 1`

and I can write the same code using a functor in Javascript.

`const nextNumFn = myNumFn.map(n => n+1)`

This is more code, as Javascript lacks native syntax for functors, but the two statements serve the same purpose: creating a new value given an existing value and a computation. The advantage with a functor is that it further abstracts you from the runtime complexity of values. Unlike with a symbol, the functor can represent a nullable value, a collection of values, or a promise, all without changing the code to compute new values from old. This abstraction is driven by the utility of the `map`

function, which forces you to package your computation as a function, but allows the functor to execute that computation in whichever way it chooses.

Map has a lot of moving parts, but if you’ve ever used a Javascript array, you already know how it works. Map starts with an existing functor, which I’ll refer to as the “starter.” You then call map with some computation—a function which accepts the value of the starter as an argument and returns a new value. Functors are functional, so the computation doesn’t alter the starter’s values in place. Instead, map returns a new functor, which represents the values of our starter once the computation is applied to them.

Functors have a value type. A functor might only ever contain a string at runtime. It might represent many strings, or no strings, but the values are always strings. Functors themselves have a type, which isn’t to be confused with the type of values in represents. The type of functor dictates how values are stored and how computations are applied. A maybe functor represents a value that might or might not be there. If I have a maybe functor representing a string value and I want to check the strings length, I would use

```
const myLength =
myString.map(s => s.length)
```

Now I have a new maybe functor, `myLength`

. If `myString`

has a string at runtime, `myLength`

will get a length at runtime. If `myString`

does not have a string at runtime, `myLength`

will not get a length at runtime. I could then map `myLength`

into another functor—checking if the length is greater than fifty to produce a boolean functor—all without worrying about a missing string. The code to apply a computation does not depend on the logistics of runtime values.

I am allowed to change what type of functor `myString`

is without updating any map calls. If `myString`

is forced to wait on a value from a service, I could turn `myString`

into a promise without altering the creation of `myLength`

. There are many functor types. Mapping a functor always returns a functor of the same type, so starting with a promise would create a bunch of promise functors.

There is one guarantee that all functor types are required to make. The code

```
const isLong = myString
.map(str => str.length)
.map(size => size > 70)
```

must be equivalent to

```
const isLong = myString
.map(str => str.length > 70)
```

Here we see two versions of producing the `isLong`

functor. In the first version, we map to our length functor, and then we immediately map into our `isLong`

functor. In the second version, we combine both computations into one function. The second computation is perfectly equivalent to the two separate computations in series; it’s a composite. The second version uses an equivalent computation to the first, and so the functor is required to produce an equivalent `isLong`

functor as a result.

To put this more explicitly, functors must ensure that sequential calls to `map`

will return an equivalent functor to a singular call to map with a composite function. $F.map(f).map(g) = F.map(g \circ f).$ This single restrictions creates many indirect restrictions. It means that functors aren’t allowed to reject the results of a computation. Imagine instead of a Maybe functor we used a “anything but a number” functor, which rejects numerical values. The first version with the split computation would fail, whereas the next version would complete. That is not allowed. If the first functor has values at runtime, and you map the functor, it has to create a new functor of the results of sending values through the computation.

Functors are otherwise given leeway in how computation is performed. Depending on the availability of runtime values, computation functions can be run many times, at arbitrary times, or not at all, as long as the functor doesn’t alter or reject the values received from the computation. The List functor runs the map for each of its many values, a Future functor runs the map once its value arrives, and the Stream functor runs the map for its many values as they arrive.

Mapping functors is a completely stateless and deterministic action. A compiler could actually run all of this code without any runtime values. A Maybe functor already has an empty state, so do lists, promises, and streams. If you wished to run the code to create all of the functors for analysis, maybe to see the connections between functors as a flow chart, that would be possible without any mocking of runtime values. This comes down to the code being naturally split between functor creation and computation execution.

See monads next.