# Mindshift: Part 6

# Boolean Values and Pairs

If you’ve been following my series of Mindshift blogs, then I trust that I have been able to communicate how we can perform basic arithmetic using nothing more than abstract quantity functions.

The previous blog showed how by starting from an abstract quantity function for `ZERO`

and then applying a `SUCC`

successor function, we can perform a variety of simple arithmetic operations.

However, we were only able to implement those arithmetic operations that make use of repeated addition. Consequently, we were limited to performing addition, multiplication and exponentiation. There was no mention of how subtraction could be performed.

So let’s fill in this gap in our capability; but in order to do so, we must first understand two apparently unrelated topics. How can we use abstract functions to represent:

- A pair of values
- A predicate

## Pear, Pare, Pair…

So first of all, we need a way of representing a pair of values. (Why this is so will become clearer in the later blogs).

To create a `PAIR`

, we will create a function that takes three parameters. The first two parameters represent the two values from which the pair is formed, and the third parameter is a function that performs some operation on the values in the pair: for instance, giving back either the first or second value:

This abstract function is structured such that you start by passing it only two of the three required parameters.

Remember the discussion about partial functions? A partial function is a function that knows how to perform only * part* of an operation. In this case, we have built a partial function that knows the value of two parameters (the values forming our pair), but has no idea

*function those two parameters should be passed to.*

**which**The trick to getting either the first or second value out of the pair is to pass the `PAIR`

partial function a function that returns either the first or second parameter.

So now we need to define a pair of functions that will extract either the first or last item from the pair. Here we could choose from quite a few different name pairs: we could call these functions:

`FIRST`

and`LAST`

, or`FIRST`

and`SECOND`

, or`LEFT`

and`RIGHT`

, or`HEAD`

and`TAIL`

, or`CHARLIE`

and`BILL`

(uh, no…forget that last suggestion).

Here, I’ll use the names `HEAD`

and `TAIL`

because these will be more generally useful for topics that are coming in the future (such as lists).

As you can see, the `HEAD`

and `TAIL`

functions are pretty dumb. They both take two parameters (`val1`

and `val2`

) and without performing any “processing”, brainlessly return either the first or second parameter.

Let’s create an example of a `PAIR`

in which we will store the names of two colours. We can then extract the first and second items by passing the colour partial function either `HEAD`

or `TAIL`

as a parameter. In doing so, we will extract either the first or second item of the `PAIR`

.

Whilst it might be a little strange to have to write `colours(HEAD)`

instead of `HEAD(colours)`

, at least we have a mechanism for extracting the first and second values from the pair. At the end of this blog, we’ll correct this slightly non-intuitive usage of `HEAD`

and `TAIL`

.

Now for predicates…

## Predicates

In technical terminology, any function that evaluates to either `true`

or `false`

is said to be a “predicate”.

Restating that in non-technical terminology, a predicate is the “*is*” operator. So for instance, the statement “Chris is typing” is a predicate because it is either `true`

or `false`

.

In computer programming, predicates are used to create a two-way branches in program logic. So the question is this “*How can we create a predicate using only a minimal function?*”.

Let’s take a typical condition as implemented in a familiar imperative language such as JavaScript. Using this as our starting point, we can work our way towards an abstract function definition.

OK, that’s simple enough…

Now let's start to abstract this coding. The first thing to replace is the specific details of the condition. The details of how the test is performed can be hidden away inside a predicate function:

Fine, that’s not too demanding. But let’s really start to strip things back to the bare minimum.

Strictly speaking, the `if`

and `else`

keywords are simply syntactic markers that indicate firstly the presence of a two-way branch in the program logic, and secondly what statements each branch should contain.

In the minimal world of abstract functions, we can certainly live without the `else`

keyword, and possibly even the `if`

keyword (see footnote 1).

JavaScript offers us an `if`

/`then`

/`else`

construct that does not require the use of either the `if`

or `else`

keywords. This is called the ternary operator and it is structured as follows:

```
<predicate> ? <true_expression> : <false_expression>;
```

A predicate is immediately followed by two expressions: the first to be returned if the predicate evaluates to `true`

, and the second if the predicate evaluates to `false`

(see footnote 2).

Since we know that the function `is_sbp`

is a predicate (meaning it can only return `true`

or `false`

), we can examine both paths the logic could take by replacing the predicate with its two possible return values.

So the behaviour here is really simple: when the predicate evaluates to `true`

, the first expression is returned, and when the predicate evaluates to `false`

, the second expression is returned.

But hang on a minute, haven’t we just looked at some coding that does exactly the same thing to a pair of values?

The coding that evaluates a predicate and then decides what value to return uses exactly the same logic as the coding to extract the first or second item from a `PAIR`

.

So let’s make two changes to the `is_sbp`

predicate function

- Instead of returning the JavaScript primitives
`true`

and`false`

, our predicate function`is_sbp`

will now return the abstract functions`HEAD`

and`TAIL`

- The two possible responses (
`pigs.fly`

and`elephants.jump`

) are now stored in a`PAIR`

partial function

## So Where Are All the Booleans?

From the coding above, we can see that extracting the first item from a list is functionally identical to when the predicate of the ternary operator evaluates to `true`

. Similarly, extracting the second item from a list is functionally identical to when the predicate of the ternary operator evaluates to `false`

.

If fact, we could argue that when applied to a `PAIR`

function, the `HEAD`

and `TAIL`

functions are nothing more than synonyms for `TRUE`

and `FALSE`

. So if we rename `HEAD`

and `TAIL`

to `TRUE`

and `FALSE`

, the coding behaves exactly the same way.

In the following code, we’ll also rename the parameters passed to `TRUE`

and `FALSE`

in order to make their usage clearer; but other than changing some names, the functionality is identical.

So where the function `is_sbp`

previously returned `HEAD`

and `TAIL`

, we’ll change it so that it now returns the abstract functions `TRUE`

or `FALSE`

. But other than fiddling around with the function names, the functionality remains completely unchanged.

If you’ve followed the reasoning so far, then I trust you should see that when represented as abstract functions, `TRUE`

and `FALSE`

are simply the `HEAD`

and `TAIL`

functions in disguise.

## Summary

The key learning points from this blogs are:

- The
`PAIR`

abstract function is a vital building block for creating more complex data structures – that we’ll look at in the next few blogs - When represented as abstract functions, the Boolean values of
`TRUE`

and`FALSE`

are functionally indistinguishable from the`HEAD`

and`TAIL`

functions

## Oh, and by the way…

Now that we have the `TRUE`

and `FALSE`

functions, we will use those as the primary means for extracting the first or second item from a `PAIR`

.

We are now free to rewrite the `HEAD`

and `TAIL`

functions to make their usage more intuitive.

Chris W

All source code from the Mindshift blog series can be found on GitHub

### Footnotes

If you find yourself perplexed or confused by the idea that a programming language does not require the

`if`

keyword, then you should consider learning Erlang.The

`if`

keyword does exist in Erlang, but its really just syntactic sugar and if you use Erlang correctly, will hardly need to use it. This is because conditions in Erlang are typically implemented implicitly by means of function signatures, rather than explicitly by means of a keyword.A word of caution about implementing the concepts of functional programming in a language that performs strict evaluation (such as JavaScript or Ruby).

When creating an

`if`

/`then`

/`else`

construct using JavaScript arrow functions, you must ensure that only one branch of the condition is evaluated.

The problem with strict languages such as JavaScript is that they always evaluate expressions as soon as they are encountered. So when writing a condition using these abstract functions, you must avoid creating the nonsensical situation in which JavaScript tries to evaluate both the true **and** false branches of a condition!

This is particularly important when implementing recursion. See the difference between the Y-Combinator and the Z-Combinator.