Here's `compose`

:

def compose(*functions):return functools.reduce(lambda f, g: lambda *x: f(g(*x)), functions, lambda x: x)

... Don't be scared! This is the level-9000-super-Saiyan-form of *compose*. For the sake of reasoning, let's drop the variadic implementation and consider a simpler form that can compose two functions together. Once you get your head around that, you can push the abstraction further and consider it simply works for any number of functions (we could even prove that)! Here's a more friendly *compose* for you my dear readers:

compose2 = lambda f, g: lambda x: f(g(x))

`f`

and `g`

are functions and `x`

is the value being "piped" through them.

Composition feels like function husbandry. You, breeder of functions, select two with traits you'd like to combine and mash them together to spawn a brand new one. Usage is as follows:

to_upper_case = lambda x: x.upper()exclaim = lambda x: f'{x}!'shout = compose(exclaim, to_upper_case)shout('send in the clowns') # "SEND IN THE CLOWNS!"

The composition of two functions returns a new function. This makes perfect sense: composing two units of some type (in this case function) should yield a new unit of that very type. You don't plug two legos together and get a lincoln log. There is a theory here, some underlying law that we will discover in due time.

In our definition of `compose`

, the `g`

will run before the `f`

, creating a right to left flow of data. This is much more readable than nesting a bunch of function calls. Without compose, the above would read:

shout = lambda x: exclaim(to_upper_case(x))

Instead of inside to outside, we run right to left, which I suppose is a step in the left direction (boo!). Let's look at an example where sequence matters:

head = lambda x: x[0]reverse = lambda x: x[::-1]last = compose(head, reverse)last(['jumpkick', 'roundhouse', 'uppercut']) # 'uppercut'

`reverse`

will turn the list around while `head`

grabs the initial item. This results in an effective, albeit inefficient, `last`

function. The sequence of functions in the composition should be apparent here. We could define a left to right version, however, we mirror the mathematical version much more closely as it stands. That's right, composition is straight from the math books. In fact, perhaps it's time to look at a property that holds for any composition.

# associativitycompose(f, compose(g, h)) === compose(compose(f, g), h);

Composition is associative, meaning it doesn't matter how you group two of them. So, should we choose to uppercase the string, we can write:

compose(to_upper_case, compose(head, reverse));// orcompose(compose(to_upper_case, head), reverse);

Since it doesn't matter how we group our calls to `compose`

, the result will be the same. That allows us to write a variadic compose and use it as follows:

# previously we'd have to write two composes, but since it's associative,# we can give compose as many fn's as we like and let it decide how to group them.last_upper = compose(to_upper_case, head, reverse)loud_last_upper = compose(exclaim, to_upper_case, head, reverse)arg = ['jumpkick', 'roundhouse', 'uppercut']last_upper(arg) # 'UPPERCUT'loud_last_upper(arg) # 'UPPERCUT!'

Applying the associative property gives us this flexibility and peace of mind that the result will be equivalent. One pleasant benefit of associativity is that any group of functions can be extracted and bundled together in their very own composition. Let's play with refactoring our previous example:

loud_last_upper = compose(exclaim, to_upper_case, head, reverse)# -- or ---------------------------------------------------------------last = compose(head, reverse)loudLastUpper = compose(exclaim, toUpperCase, last)# -- or ---------------------------------------------------------------last = compose(head, reverse)angry = compose(exclaim, to_upper_case)loud_last_upper = compose(angry, last)# more variations...

There's no right or wrong answers - we're just plugging our legos together in whatever way we please. Usually it's best to group things in a reusable way like `last`

and `angry`

.

Pointfree style means never having to say your data. Excuse me. It means functions that never mention the data upon which they operate. First class functions, currying, and composition all play well together to create this style.

Hint: Pointfree versions of replace & to_lower_case are defined in the Appendix A. Do not hesitate to have a peek!

# not pointfree because we mention the data: wordsnake_case = lambda x: replace(' ','_', x.lower())# pointfreesnake_case = compose(replace(' ', '_'), to_lower_case)

See how we partially applied `replace`

? What we're doing is piping our data through each function of 1 argument. Currying allows us to prepare each function to just take its data, operate on it, and pass it along. Something else to notice is how we don't need the data to construct our function in the pointfree version, whereas in the pointful one, we must have our `word`

available before anything else.

Let's look at another example.

# not pointfree because we mention the data: nameinitials = lambda name: '. '.join(map(compose(to_upper_case, head), name.split(' ')))# pointfreefmap = curry(lambda fn, xs: [fn(x) for x in xs])fsplit = curry(lambda pattern, s: s.split(pattern))fjoin = curry(lambda pattern, s: pattern.join(s))initials = compose(fjoin('. '), fmap(compose(to_upper_case, head)), fsplit(' '))initials('hunter stockton thompson') # 'H. S. T'

Pointfree code can again, help us remove needless names and keep us concise and generic. Pointfree is a good litmus test for functional code as it lets us know we've got small functions that take input to output. One can't compose a while loop, for instance. Be warned, however, pointfree is a double-edged sword and can sometimes obfuscate intention. Not all functional code is pointfree and that is O.K. We'll shoot for it where we can and stick with normal functions otherwise.

A common mistake is to compose something like `map`

, a function of two arguments, without first partially applying it.

# wrong - we end up giving angry an array and we partially applied map with who knows what.latin = compose(map, angry, reverse)latin(['frog', 'eyes']) # error# right - each function expects 1 argument.latin = compose(fmap(angry), reverse)latin(['frog', 'eyes']) # ['EYES!', 'FROG!']

If you are having trouble debugging a composition, we can use this helpful, but impure trace function to see what's going on.

@currydef trace(tag, x):print(tag, x)return xdasherize = compose(fjoin('-'),to_lower_case,fsplit(' '),replace(r'(\s+)', ' '),)dasherize('The world is a vampire')# AttributeError: 'list' object has no attribute 'lower'

Something is wrong here, let's `trace`

dasherize = compose(fjoin('-'),to_lower_case,trace('after split'),fsplit(' '),replace(r'(\s+)', ' '),)dasherize('The world is a vampire') # after split ['The', 'world', 'is', 'a', 'vampire']

Ah! We need to `fmap`

this `to_lower`

since it's working on an array.

dasherize = compose(fjoin('-'),fmap(to_lower_case),fsplit(' '),replace(r'(\s+)', ' '),)dasherize('The world is a vampire') # 'the-world-is-a-vampire'

The `trace`

function allows us to view the data at a certain point for debugging purposes. Languages like Haskell and PureScript have similar functions for ease of development.

Composition will be our tool for constructing programs and, as luck would have it, is backed by a powerful theory that ensures things will work out for us. Let's examine this theory.

Category theory is an abstract branch of mathematics that can formalize concepts from several different branches such as set theory, type theory, group theory, logic, and more. It primarily deals with objects, morphisms, and transformations, which mirrors programming quite closely. Here is a chart of the same concepts as viewed from each separate theory.

Sorry, I didn't mean to frighten you. I don't expect you to be intimately familiar with all these concepts. My point is to show you how much duplication we have so you can see why category theory aims to unify these things.

In category theory, we have something called... a category. It is defined as a collection with the following components:

A collection of objects

A collection of morphisms

A notion of composition on the morphisms

A distinguished morphism called identity

Category theory is abstract enough to model many things, but let's apply this to types and functions, which is what we care about at the moment.

**A collection of objects** The objects will be data types. For instance, `String`

, `Boolean`

, `Number`

, `Object`

, etc. We often view data types as sets of all the possible values. One could look at `Boolean`

as the set of `[true, false]`

and `Number`

as the set of all possible numeric values. Treating types as sets is useful because we can use set theory to work with them.

**A collection of morphisms** The morphisms will be our standard every day pure functions.

**A notion of composition on the morphisms** This, as you may have guessed, is our brand new toy - `compose`

. We've discussed that our `compose`

function is associative which is no coincidence as it is a property that must hold for any composition in category theory.

Here is an image demonstrating composition:

Here is a concrete example in code:

g = lambda x: len(x)f = lambda x: x == 4is_four_letter_word = compose(f, g)

**A distinguished morphism called identity** Let's introduce a useful function called `id`

. This function simply takes some input and spits it back at you. Take a look:

id = lambda x: x

You might ask yourself "What in the bloody hell is that useful for?". We'll make extensive use of this function in the following chapters, but for now think of it as a function that can stand in for our value - a function masquerading as every day data.

`id`

must play nicely with compose. Here is a property that always holds for every unary (unary: a one-argument function) function f:

# identitycompose(id, f) == compose(f, id) == f# True

Hey, it's just like the identity property on numbers! If that's not immediately clear, take some time with it. Understand the futility. We'll be seeing `id`

used all over the place soon, but for now we see it's a function that acts as a stand in for a given value. This is quite useful when writing pointfree code.

So there you have it, a category of types and functions. If this is your first introduction, I imagine you're still a little fuzzy on what a category is and why it's useful. We will build upon this knowledge throughout the book. As of right now, in this chapter, on this line, you can at least see it as providing us with some wisdom regarding composition - namely, the associativity and identity properties.

What are some other categories, you ask? Well, we can define one for directed graphs with nodes being objects, edges being morphisms, and composition just being path concatenation. We can define with Numbers as objects and `>=`

as morphisms (actually any partial or total order can be a category). There are heaps of categories, but for the purposes of this book, we'll only concern ourselves with the one defined above. We have sufficiently skimmed the surface and must move on.

Composition connects our functions together like a series of pipes. Data will flow through our application as it must - pure functions are input to output after all, so breaking this chain would disregard output, rendering our software useless.

We hold composition as a design principle above all others. This is because it keeps our code simple and reasonable. Category theory will play a big part in software architecture, modelling side effects, and ensuring correctness.