Trying to apply the concepts I learned while studying Haskell to PHP with various degrees of success. In this post I explore what an implemenation of a Functor could look like in PHP.

## Introduction

*Disclaimer: I do not recommend for you to write production code like this. This is a thought experiment and should be treated as such. I attempt to apply certain concepts that I learned in the context of Haskell to PHP. The implementation can become fairly obscure and complex. They only serve educational purposes.*

Recently, I have been learning Haskell using this book. Especially the later parts of the book pique my interest. In there, the authors talk about the more intimidating topics such as Monads, Monoids and Semigroups.

As I learn about the theory, I am always curious how I can apply this knowledge to other languages. Since in my day job I work in PHP, this is the language I am most interested in. Figuring out if and how I can apply a topic to a completely different programming paradigm helps me deepen my understanding. One of these topics is the `Functor`

typeclass.

What follows are my notes on trying to apply what I learned to PHP.

## Things we already now

Every PHP developer is familiar with arrays. In PHP, they are the One Datatype To Rule Them All™. As such, most of us will be familiar with the notion of *mapping* a function over an array like so:

```
$arr = [1, 2, 3, 4];
$mapped = array_map(function ($x) {
return $x + 1;
}, $arr);
// $mapped is now [2, 3, 4, 5]
```

What `array_map`

is doing, is to first apply the callback to every element in the array. It then returns a new array containing the result of function applications. In the above example, we just added `1`

to every element in the list. Easy stuff.

## Things we might not know

What if I told you that *mapping* is not specific to arrays at all. In fact, it has nothing to do with arrays per se. That is just an implementation of a much more general pattern.

If you have mainly worked in PHP, this may come as a surprise to you. In the context of PHP, we only really come into contact with mapping when we deal with arrays. Assuming that it is an operation inherit to lists might not seem too far fetched.

Let’s now think about what `array_map`

is doing on a more general level. Instead of saying that we iterate over the list, applying the callback to each element, let’s try and find a more general description. Another way to describe `array_map`

, is that it takes a function that operates on a single value and makes it work on lists.

Here is yet another way to look at it. What we are really interested in, is the values *inside* of our list. We want to apply some operation (or transformation) to these elements. The issue is that our elements are wrapped in this container-like structure, the array. Since our function only operates on single values, we need a way to *reach inside* this structure and pull out the individual values. That allows us to then apply our function to a single value. After that we put the result of this computation into another list which gets returned at the very end. That means, that `array_map`

is **structure-preserving**. We started with an array and we end up with (1) another array (2) *of the same length*. We changed the values *inside* the structure, but not the structure itself.

If this all sounds really abstract and confusing, don’t worry. It will hopefully all make sense in a bit.

## Some notation

Let me introduce some notation. I will try to keep this to a minimum. However knowing how to read this notation really helps for the coming parts.

Suppose we have something like this:

`add1 :: Int -> Int`

The way you read this expression is

`add1`

is a function, that takes an`Int`

and returns an`Int`

Here’s another one:

`add :: Int -> Int -> Int`

This reads

`add`

is a function, that takes an`Int`

and an`Int`

and returns an`Int`

Treat the last thing as the return type and everything else as arguments*. One last example to demonstrate what a function looks like that takes another function as an argument (a so-called higher-order function ).

`filter :: (a -> Bool) -> [a] -> [a]`

`filter`

is a function, that takes another function, that takes an`a`

and returns a`Bool`

, and a list of`a`

and returns a list of`a`

.

In this example `a`

can be any type. We’re not restricted to, say, `Int`

for example.

Ok, I hope that wasn’t too bad. Let’s move on.

## Make it functor…y

I mentioned above, that mapping is not specific to lists. If that’s the case, we should be able to *generalise* the concept of mapping over something. Turns out we can! This is called a `Functor`

. A functor is something that is *mappable*.

This is an example of a type class . Think of a type class as something very close to an interface. It defines a list of functions that a type has to implement if it wants to act as an instance of that type class. Here’s the definition of `Functor`

in Haskell.

```
class Functor f where
fmap :: (a -> b) -> f a -> f b
```

Let’s go through this slowly.

First of all, do not get confused by the word `class`

. It has nothing to do with classes in OOP. It means class, as in type class. So we’re defining a type class called `Functor`

. This type class takes a single type parameter `f`

. What does that mean? If you’ve ever worked with Java, you know that you can never have just a `List`

. It’s always a list *of something*. `List<String>`

, `List<Int>`

, `List<List<String>>`

and so on. So `List`

takes a type parameter. What that means for us, is that in order for something to be a functor, it needs to take exactly one type parameter. In other words, it needs to be a *type constructor*.

The method that we need to implement for something to be a functor is called `fmap`

. Let’s see what the function signature tells us.

`fmap`

is a function, that takes a function from`a`

to`b`

, a functor of`a`

and returns a functor of`b`

If you understood that, then pat yourself on the back. If not, read on.

### Deciphering fmap

Remember, I said that functor means *mappable*. We already know, that we can map over lists. So from that we can deduce that lists are functors.

Let’s get rid of all this abstract nonsense and look at the type signature of `fmap`

for lists. That means just replace every occurrence of `f`

with `[]`

, which is the list constructor.

`fmap :: (a -> b) -> [a] -> [b]`

Aha! That makes a lot more sense. We take a function from `a`

to `b`

and a list of `a`

and return a list of `b`

. That looks like our good friend `array_map`

.

`array array_map(callable $callback , array $array)`

The `callable`

is our function `(a -> b)`

. The `$array`

we take as an argument is our `[a]`

(or `f a`

in the original definition). And we return another array, which corresponds to `[b]`

(or `f b`

). Of course, since PHP is dynamically typed we lose some information about the types. The PHP equivalent of `fmap`

for arrays would look something like this.

`fmap :: callable -> array -> array`

But let’s stick with the original definition and just pretend that PHP was statically typed. Trust me, it makes all this much easier to understand.

### Defining an interface

Let’s take the above definition of `Functor`

and translate it to a PHP interface. It would look something like this.

```
interface Functor
{
public function fmap(callable $fn): Functor
}
```

*Note: I’m using PHP 7 type hinting here to stick more closely to the original definition. It is not strictly needed for any of this to work.*

We’re doing this in an object-oriented way. That means our version of `fmap`

takes only a single parameter, the callback. The functor instance itself would be the seconds argument. So instead of

`fmap($myFunction, $functor);`

we get

`$functor->fmap($myFunction);`

Again, due to the dynamic nature of PHP we lose some information about the types. There is no way for us to parameterise our `Functor`

interface over a type. But this is as close as we can get.

Now that we have an actual PHP interface, let’s try and write a few classes that implement this interface.

## Creating our own array

The easiest way to get our feet wet with this functor thing is by just reimplementing our trusty array using the functor interface. So let’s try that.

```
class Arr implements Functor
{
protected $items;
public function __construct(array $items)
{
$this->items = $items;
}
public function fmap(callable $fn): Functor
{
return new static(array_map($fn, $this->items));
}
}
```

Essentially, what we have here is a very simple wrapper around an array. For brevity’s sake, I did not implement any of the array interfaces (like `ArrayAccess`

). We don’t need them for this.

As you can see, `fmap`

for our little array wrapper is simply `array_map`

! The only extra thing we need to do, is wrap the result into another instance of our new class. We have to do that because our functor interface dictates that `fmap`

needs to return another `Functor`

. Let’s try the example from above with our shiny new class.

```
$add1 = function ($x) { return $x + 1; };
$arr = new Arr([1, 2, 3, 4]);
$mappedArr = $arr->fmap($add1);
// Arr([2, 3, 4, 5])
```

Works as expected, neat.

## That’s enough (for now)

If you made it all the way to here, congratulate yourself.

Looking back at it, this really didn’t teach us all that much. We basically ended up in the same place as before, but now with a crappy home-brewed implementation of an array.

The purpose of part 1 was mostly to introduce the idea that *mapping over something* can be generalised. I also tried to gently introduce some notation that will help us understand part 2.

So if this felt a bit underwhelming, do not fret! In the next part we’re going to apply our newfound knowledge about functors to things that aren’t arrays! If that does not excite you, you have no soul (or something like that).

So see you soon for part 2!