# On the Matter of Function Signatures

Programmers tend to click on function names to read the implementation to understand what a function actually does. Often software engineers consider this a main tool of their IDE. I lately come to think of that behaviour as a smell. I would like to enhance my functions to be able to tell everything from just looking at the (type) signature.

*tl;dr:* Total, pure and well typed functions lead to function signatures that tell the user everything she needs to know.

Bold statement. Let me elaborate on that.

## On Functions

Mathematically a function is a rule that maps entries from one set onto another set. We actually know that from basic math: The function **inc = x + 1** maps all numbers x to their respective successors. The signature for an implementation of that function would look something like that:

We expect an integer output for every integer put in. We do not expect anything else from that function and would be utterly surprised getting a string back or something completely different. We want to trust that implementation. Have another look at simple math:

From the signatures we read that every pair of integer input will return an integer output for every operation.

We can guess that **dvd** will actually give us the quotient and drop the remainder. Easy. But there is one other problem with **dvd**: It simply lies about its mapping rule.

We know, that the division by **0** is not defined. In math we would respond with **undefined** or **not permitted**. But that very response is a string rather than an integer and we are surprised. Maybe it’s not a string that is returned but an error message thrown through an exception that puts the whole program to halt. We would be stunned in surprisal for the sheer amount of effect. And we should be! The signature is lying to us!

What happens in the **dvd** function? Let's look at the internals:

It’s easy to see that division by zero throws an exception. But we had to look up the implementation. And again, I would rather not have to do that.

## Total Functions

The implementation of **dvd** is called a partial function. Mathematically speaking we can only apply the function to a part of our set (**Integer\{0}**) for the second parameter.

A total function is a function that can be applied to the whole set. To get to a total function we have to reduce the set for the second parameter. We can do that easily by defining a new type:

With that type in place we can redefine our **dvd** function:

At first glance we see that the function got a whole lot easier. We actually don't need to look at the implementation anymore to understand the function in its whole.

* Side note:* I use the implementation of

**dvd**here that mimics

**div**to make my point with a simple example; but note that there is an ongoing discussion about the partial function

**div**to be valuable for compiler optimisation. Since my point is to have total knowledge of function implementation through function signature I consider all partial functions of non-valuable for

*that purpose*.

## Pure Functions

Let’s go back to our **inc** function for a moment and have a look at an alternative possible implementation:

I had to use pseudo code here since Haskell enforces purity and therefore the side effect wouldn't be possible. But bare with me for a second and try to grasp the underlying problem: The function signature is lying *again* about what is actual happening. We give it an integer value and get an integer value back. That does work for all integer values in the bounds of **Int** and therefore fulfils the requirement of totality.

But it is impure.

A function is considered pure if it has no effects. It just provides a (input dependent) value. A pure function can always be written as a table. Consider a pure **add** function as a table:

There’s no possibility for that table doing anything else than just adding two numbers.

With pure functions we have to think less about the implementation because we have to think less about implications of application. What matters is the function signature. We are able to trust that even more.

## Container Types

Let’s go back to our **dvd** example for a moment. There is another possible solution to that problem: Application of container types to enhance the set of possible return values instead of reducing the set of possible inputs. To introduce another simple example, we could apply the Maybe type to tell the user that she might not get an Int value back:

We could also have used **Either** or may have defined some type **IntOrUndefined** to make the possibility of failure *explicit*.

Either way; we get a function signature that we can trust telling us *what may happen*. No more surprises here.

## Capstone: It's all about Communication

Having solid function signatures is a matter of communication and precision. Creating a function I want to express my intention explicitly. And on the other hand I prefer knowing what a function does by just looking at its signature. A statically typed language like Haskell or Java can help with that by providing very precise type signatures.

I would love seeing more developers picking up trust in the informations they get just looking at function signatures in the future and stop looking at the implementation details.