Episode #1: Functions

Introduction

Thanks for joining us for the first episode of Point-Free! Point-Free is going to cover a lot of functional programming concepts so let’s start by defining what a function is: a computation with an input and output.

Let’s define a function. We can define an increment function that takes an Int and returns an Int:

func incr(_ x: Int) -> Int {
  return x + 1
}

To call our function, we pass a value to it.

incr(2)  // 3

Now let’s define a square function to square an integer:

func square(_ x: Int) -> Int {
  return x * x
}

We can call it in a similar fashion:

square(2)  // 4

We can even nest our function calls. In order to first increment, then square a value:

square(incr(2))  // 9

1:08

This is pretty simple, but it’s not very common in Swift. Top-level, free functions are generally avoided in favor of methods.

We can define incr and square as methods by extending Int:

extension Int {
  func incr() -> Int {
    return self + 1
  }

  func square() -> Int {
    return self * self
  }
}

To use our incr method, we can call it directly:

2.incr()  // 3

And we can square the result by chaining our method calls:

2.incr().square()  // 9

1:50

This reads nicely from left-to-right whereas free functions read from inside-out, and it takes more mental work to see that we call incr before we call square. This is probably why free functions are less common in Swift. A very simple expression is much more difficult to read using traditional function calls. We can imagine that a more complicated nest of function calls would be all the more difficult to unpack. Methods don’t have this problem.

Introducing |>

2:21

There are several languages out there that have free functions but retain this kind of readability by using an infix operator for function application. Swift lets us define our own operators, so let’s see if we can do the same.

infix operator |>

2:34

Here we’re defining a “pipe-forward” operator. It’s based on prior art: F#, Elixir, and Elm all use this operator for function application.

To define this operator, we write a function:

func |> <A, B>(a: A, f: (A) -> B) -> B {
  return f(a)
}

2:50

It’s generic over two types: A and B. The lefthand side is our value, of type A, while the righthand side is a function from A to B. We finally return B by applying our value to our function.

Now we can take a value and pipe it into our free function.

2 |> incr  // 3

We should be able to take this result and pipe it into another free function:

2 |> incr |> square

3:26

But we get an error.

Adjacent operators are in non-associative precedence group 'DefaultPrecedence'

When our operator is used multiple times in a row, Swift doesn’t know which side of the operator to evaluate first. On the lefthand side, we have:

2 |> incr

2 piped into incr makes sense, since incr takes an integer. On the righthand side, we have:

incr |> square

3:50

Piping our incr function into our square function makes less sense: square expects an integer, not a function.

We need to give Swift a hint as to which expression to evaluate first. One way to do this is to wrap the lefthand expression with parentheses so it evaluates first.

(2 |> incr) |> square  // 9

4:00

This works but it’s kind of messy. This is a pretty simple composition, but a more complicated example would require more nested parentheses and would be more difficult to follow. Let’s give Swift a better hint.

Swift lets us define the associativity of an operator by using a precedence group. Let’s define a precedence group for function application:

precedencegroup ForwardApplication {
  associativity: left
}

4:20

We gave it a left associativity to ensure that the lefthand expression evaluates first.

Now we need to make sure our operator conforms to our precedence group.

infix operator |>: ForwardApplication

4:35

We can now get rid of our parentheses.

2 |> incr |> square  // 9

This looks a lot like our earlier method version:

2.incr().square()  // 9

Operator interlude

4:54

We’ve solved the readability problem of nested functions, but we have a new problem: custom operators. Custom operators aren’t very common. In fact, many of us avoid them because they have a bad reputation. A typical encounter with custom operators is within a subset of the idea: overloaded operators.

For example, in C++ you can’t define new operators, but you can overload existing operators the language provides. If we were to write a vector library in C++, we could overload + to mean the sum of two vectors and we could overload * to mean the dot product of two vectors. Then again, * could mean the cross product of two vectors, so any choice to use * is going to require an opinion and lead to confusion.

We would never suggest overloading multiplication with function application:

2 * incr  // What does this mean!?

5:54

It would be very difficult to encounter this in a code base and understand what it means.

Luckily we don’t have this problem here. We’re using a brand new operator, |>, which Swift has no prior knowledge about. One may argue that an operator that Swift doesn’t know about is an operator that a Swift developer doesn’t know about, but in this case, we’re looking to prior art: F#, Elixir, and Elm all use this operator in the same way. Swift engineers that are familiar with these languages are going to be familiar with the operator. It also has a nice shape! The pipe (|) evokes Unix, where we pipe the output of programs as input into other programs. The arrow also goes to the right (>), which gives us a nice left-to-right reading. Let’s look back at our usage of this operator:

2 |> incr

6:34

Even if we’re not familiar with this operator, we can kind of piece together what’s going on here.

We’re going to be using operators a lot in Point-Free, so let’s make sure that we’re responsible and justify the symbols that we introduce. There are a few boxes we’ll want tick before we should introduce a new operator:

We shouldn’t overload an operator with existing meaning with new meaning.
We should leverage prior art as much as possible and make sure our operator has a nice “shape” that evokes its semantics: in this case |> nicely describes piping a value forward into a function.
We shouldn’t be inventing operators to solve very domain-specific problems. We should only introduce operators that can be used and reused in very general ways.

Our |> operator ticks all these boxes.

What about autocompletion?

7:38

While operators give us this readability, we’re still missing a feature that methods have: autocomplete.

In Xcode, we can refer to a value, type a dot, and be presented with a whole list of methods we can call on this value.

We can even type a few characters to limit the list to a subset of methods, including our incr method.

This is really nice for code discoverability, and is a nice win for methods, but autocomplete really doesn’t have anything to do with methods. Autocomplete works with our free functions, as well.

This is at the top-level, though, so we lose some of the scoping we get with method completion. Still, there’s nothing preventing our IDEs from understanding that, given a value and |>, should autocomplete functions that take that value as input. Hopefully this will get better with newer versions of Xcode.