I've found the process of adding to this blog to be quite a lot of friction so I stopped. For the rest of the year I mostly worked on our swimming pool (it's not quite done yet!). Was great to finally get it to a point where we could actually jump in especially during the middle of summer.

Lots of sweat, blood and tears went into this!

Rest of 2023 update

A month ago my girlfriend found a dog on the side of the road with a broken leg. It was an old injury and she was in a lot of pain. Some people had tried to catch her earlier that day but she was just too quick. She called a vet out to dart it and it was taken to the vet and unfortunately the leg had to be amputated.

Not all these stories have happy endings but this one did! She now has a new home and goes by the name Pippa. It's wonderful seeing how these dogs just get up and carry on with life.

Here she is with her new best friends. Stoked!

On a side note the foundations for the inner walls are nearly ready to pour then we can start building the inner walls. All the piles of dirt on the inside of the hole are stone that Richard and I have broken up with picks. Been a hard job chipping away at this bastard but it's been great getting some proper exercise done!

Meet Pippa

Although I'm busy with my Haskell projects in my free time I haven't done any posts on programming. I do plan to put together a series of posts at some point in the future when I feel things have gotten to the point where it's worth writing down and sharing my experiences.

On a side note we are finally building the pool (which is something we've been planning on building for the last three years - it just kept getting bigger each year). Probably a good thing we've started now, would not be able to manage another year and a bigger pool!

The dogs are going to love it, especially Fenton, Willow and Coco.

It's been great to do some hard manual labour, the first real exercise I've had in nearly two years so it's been good for me.

Still long ways to go. Here is Fenton proudly looking over his soon to be kingdom.

Summer is fast approaching, the pool will be a welcome break from the heat!

A whole lot of diggin'

This is a bit of a nothing post. Outside of my professional work I haven't managed to get much done as I've had several dogs going to the vet (fortunately all are well now!) as well as various maintenance issues to deal with.

Overall it hasn't been terrible to take a bit of a break, I started reading 

 which I finished last night. Crazy story.

Also got around to testing the soil pH in my garden, just the topsoil for now and it's bang on with the growth I'm seeing. Going to be hard to lower the pH but in the long run will have a huge effect on the garden.

Interlude

While writing a function to generate a look at matrix I came across this problem where I had to combine two monads, a Maybe and an Either. I struggled for a while to find out how I could connect the two bits together then just wrote a function to transform from Maybe to Either. I didn't like it, and was sure there was a much more elegant way to do this.

Fortunately my brother is a CTO with around ten years of production Haskell experience and I'm very lucky to be able to ask him questions about Haskell. He's also the reason I'm even doing Haskell in the first place. Thanks brother for putting up with all my questions and for showing me this amazing language!

So here's my original implementation, ended up doing a lot of fmapping and apping. I knew I could use something like liftA3 or similar but that's where I left the exercise at.

Here's the version after going over it with my brother. A dramatic improvement, and I could get rid of two redundant error cases one of which I had to add for my transformation from Maybe to Either. So the beauty of the new implementation is the computation easily short circuits on an error.

I'm really loving the expressive and declarative nature of Haskell. It's really easy to read the flow of code - it basically comments itself.

Combining Maybe and Either monads

Over the last weekend I started writing my first real Haskell project. It was high time to start attempting to tie all the pieces together. I did struggle for a while to come up with ideas for a Haskell project. Initially I was thinking of doing a web app but eventually I just decided to build a raytracer as it's a domain I understand very well having spent several years in visual effects.

So far I've written some of the math code and a couple of other random things which turned out to be a very illuminating exercise.

I am absolutely in love with Haskell! It is the most expressive language I have used by far! The strong typing is a dream to to use in comparison to the Javascript/Typescript I write during my day job. I could go on and on about how great the language and the tooling around it are, but that's all planned as a series of posts.

As I develop this project I will write about the interesting things I learn as I attempt to solve problems along the way.

I have a vague idea of how I see this project in the long term. It's going to be a raytracer with a fair number of features. Probably just implicit shapes to keep things simple. Keeping the maths fairly simple as well by focusing on just the bare minimum but still written in such a way that presents interesting problems that needed to be solved (I will write about these in due course).

For the time being I'll write the main code in Haskell as a standalone app. Once I've added a fair number of features and decided that I've reached the point where the project is no longer giving me useful problems to solve from a functional perspective I will then refactor to turn it into a server app. I will then write a Purescript frontend to send rendering data to this server which will send rendered tiles back for display in the browser. That's more or less the long term plan I have in mind, and it should present a pretty good opportunity to build a client-server application using pure functional languages!

I have started my first "real" Haskell project.

First real Haskell project

 we want to find a way to compare the two functors. We can do this if they have the same variance and they map in the same direction.

. We compare these two objects in the target category which means there is a 

 which is a family of morphisms of the target category that are indexed by the objects of the source category.

, we have the following commuting squares:

By composing the sides of the diagram we can get from 

 in two ways (here we look at the covariant side of the diagram above):

Given a natural transformation in which all the components are isomorphisms (invertible morphisms) we say this is a 

. This means isomorphic functors - they are similar.

Endofunctors in Haskell are type constructors that map types to types and functions to functions (by 

 we define a natural transformation in Haskell as a polymorphic function for all types 

This is really a family of functions parameterized by type 

The naturality condition is automatically satisfied in Haskell by virtue of the nature of polymorphic functions being defined for all types (parametric polymorphism). Therefore:

We went over the idea of functors being contexts or containers and the action of some function on a container changes the contents but not the structure. Natural transformations change the structure of the containers while leaving the contents untouched.

The naturality condition says that it doesn't matter in which order we perform this composition, we can apply the function to the contents first, then modify the structure which is equivalent to first modifying the structure and then applying the function to this modified structure.

An example of a natural transformation is 

This is because it is parametrically polymorphic and so is a natural transformation. We can verify the naturality condition:

Even some functions that don't look like natural transformations can actually be expressed so. For example:

from the Prelude library can be expressed as:

Natural transformations

Function types are special because they live in the same category as the objects they map which for our use case is 

A function type has an input type and a return type, so it is a composite type. Here we attempt to use a universal construction to create a function type which is a pattern that involves three objects; the 

This pattern is function application. We simply apply the function to the argument in order to get the return type. To begin this universal construction we take some 

 for the return type. These are all objects because we are expressing this construction in terms of arbitrary categories.

The function application itself is a mapping from the product of the function type and the argument type 

 (which is an object in some category) to some other object 

 (or more specifically for our purposes, 

 is the set of all function types, while the objects 

 are, respectively, the sets of argument and return types. Note that for 

This pattern doesn't exist in every category, but it does exist in the categories of interest to programmers. Also, this only exists in those categories which have products for all pairs of objects.

As we saw in the universal constructions of product and coproduct we need to find the best candidate for the function type. That means there is a unique mapping between these candidates and our pattern (which we take to be the best candidate). In this case we take 

We really need to close the diagram through a morphism from 

 is the best candidate, and so we do some renaming as in the diagram below:

Which gives us the formal definition of the universal function object 

This function object doesn't exist for any pair of objects in any given category but it does always exist in the category 

 as a function in two arguments. In fact, in 

 from a pair of objects (which themselves are sets - types).

Additionally the universal property tells us that for every 

In the categories of interest to us as programmers, and given the above (in those categories) we know that 

 function. This shows the equivalence of 

What might seem bizarre at first actually makes a lot of sense. Given a function 

 has some set of values (possibly infinite in Haskell), and therefore for each of those we can multiply by the set of values in 

. Remember we are dealing with objects that are actually sets as we are in our usual categories of interest.

). Let's say we map this to a hypothetical 

 which has 256 possible values (in Haskell the 

 type actually encodes Unicode). That means for every value of the argument type there are 256 possible values in the return type. Therefore the total is 

The laws of exponents map directly to types.

Function types, currying and exponentiation.

Function types

Functors are themselves morphisms in the category 

 which is the category of categories. They map one category to another. This means we can sometimes think of them as functions from one category to another category. Especially in 

This means that functors can take more than one argument, and here we will go over a 

 (or binary functor), which is a functor in two arguments. Functor has kind 

In parallel with the functor which maps objects to objects the bifunctor maps pairs of objects to another category. Given two categories 

mapping from a Cartesian product of categories

And because functors map morphisms as well the bifunctor maps a pair of morphisms, one from each category to the product category. This composition is satisfied as per the categorical rules (it is associative and has identity).

(f, g) \circ (f', g') = (f \circ f', g \circ g')

These morphisms though are an actual set, the hom-set for the given objects in the category.

The product of two objects, the categorical product, is a bifunctor. If a product exists for any pair of objects then the mapping from those objects to the product is bifunctorial.

The pair constructor is the simplest product (as we found before), and here is it's Bifunctor instance:

The action of the bifunctor here is to make pairs of types:

 type is itself a bifunctor, here is it's instance implementation:

Since ADTs are constructed from simpler data types, and we know that product and coproduct are functorial, it then follows that ADTs are also functorial as long as the type itself is parameterized (which is one of the requirements for a type to be a functor, it has kind 

Constructors that have no dependency on the functors type parameter are equivalent to the 

 functor while those that simply encapsulate the type are equivalent to the 

 functor. These are the primitives used in the product and coproduct to construct ADTs.

Now we can see types in a different light. 

 is a coproduct type which is functorial, and is therefore isomorphic to 

 is actually a bifunctor but here it is used partially applied.

Mapping a cartesian product of categories to another category.

Bifunctors

In this post I'll write about functors only in programming terms, specifically in Haskell.

 functor. A functor is not itself a type, it's a type constructor as given by the definition of the typeclass in Haskell:

 is a higher order function which takes a function 

 and "lifts" it into a function that acts on the function 

 which itself is a mapping from functor-to-functor.

This means really that we can take any ordinary function and apply it to a functor, which then will return a functor.

A list in Haskell is a coproduct type defined recursively as:

The built-in list type has a functor instance. Here's the implementation:

We simply apply the function to the head of the list, then 

 that function over the tail of the list and combine them.

This is something that is, on the surface, quite different to the functor examples shown before (

In Haskell functions are types. A partially applied function is also a type in Haskell - here we take a function 

 - it's a function that's awaiting a second type argument 

, this is also a type constructor. When it receives it's second type it becomes a full type - a total function.

This type constructor (partially applied function) defines a whole family of type constructors parameterized by the type 

 is a functor we want to lift the original function 

(r \rightarrow a) \rightarrow (r \rightarrow b)

 - it's the only way to make the two arguments typecheck. In pointfree form:

In simple terms it's a thing that takes a resource 

 which is awaiting it's argument - we have a resource 

 to which we pass as the first argument to the partially applied function 

 as above. Remember we are dealing with partially applied functions, so the whole process kicks off when we are given an 

. This is applied to the second function 

. This is just some of the detail in the context of functors.

This follows from the rules of category. Given the following function:

 which is itself a functor containing a functor. In order to apply some function 

 functor. A simple example on a list of integers that may or may not have a tail:

 in which some value(s) is/are stored. For example the 

 functor is a context that may or may not contain a value. 

 is a context that contains those values that come from I/O and are thus unpredictable, and so on.

This doesn't always make the most sense as functors like the list functor are better thought of as a 

. There are other functors like the constant functor that don't map well to this context worldview, and so are better thought of as a thing that contains something, but we don't really care about what it contains. We only care about preservation of the structure of the categories upon which the functors act on.

In a nutshell the functor typeclass allows us to apply pure functions to values that are in a context/container - this means we are separate our program logic neatly into pure and effectful parts.

Some notes on endofunctors in real life Haskell programming.

Functors in Haskell

 is a mapping between categories, possibly including itself, which is called an 

 (in Haskell we deal with endofunctors, the mapping from 

The idea of category theory is that we want to take a collection of 'things', but we don't want to look inside these 'things'. We call them objects, they are nothing more than points at best. We do need to have a way to 'compare' these objects, which is what the morphisms are for. So given a category 

 we think of all the morphisms between the objects of that category as those things which 

 a functor is defined as two assignments, one of which sends objects to objects and the other which sends morphisms to morphisms:

Src \longrightarrow Trg
\\
A \longmapsto FA
\\
f \longmapsto F(f)

And of course these assignments must respect the structure of the two categories. By the category laws the functor must preserve identity morphisms:

A \xrightarrow {id_A} A \longmapsto FA \xrightarrow {id_{FA}} FA
\\
F(id_A) = id_{FA}

and composition of composible morphisms is also preserved, but here the direction can be reversed. Given a morphism 

 can be preserved or it can be reversed. This leads to two kinds of functors, 

covariant
\\
A \xrightarrow {f} B \longmapsto FA \xrightarrow {F(f)} FB
\\
contravariant
\\
A \xrightarrow {f} B \longmapsto FB \xrightarrow {F(f)} FA

 is a coproduct type that encapsulates a unit type and some other type 

 into a functor (more correctly an endofunctor) we need to make it an instance of the 

 is indeed a functor we need to prove that the application of the functor preserves the structure of the category - that means identity and function composition:

That's just a brief introduction - there is much more to functors!

Functors 101

 is an object in a category that is equipped with two morphisms, it's projections, 

. This corresponds to the Cartesian product of the two objects 

 is an object in a category that is equipped with two morphisms, it's injections, 

. This corresponds to the disjoint union of the two objects 

 are tagged in order to signify their origin, and the union of the tagged versions of the sets is taken:

A + B = (A \times \{0\}) \cup (B \times \{1\})

For a given pair there may be many such wedges, on one side or the other. Our goal is to look for a 

. This means that for a given pair of objects 

 of the pair is a wedge with the following universal property that for each wedge there is a unique morphism 

 for each wedge (which is unique for each wedge on 

) means that the two respective wedges commute:

Given the product and coproduct wedges in the category 

. This verifies the uniqueness of the universal solution.

, a pair of product and coproduct wedges then 

 are uniquely isomorphic over the wedges. That is, the unique morphisms 

 are an inverse pair of isomorphisms, and similarly for the isomorphisms 

. This means that if a pair of objects has a product or coproduct then it is essentially unique, and which leads to us speaking of 

 product or coproduct of a pair of objects.

The existence of products and coproducts varies from category to category.

In very general terms it means we can take various types in the category 

 and two functions (projections) from each type (

), then the product tells us that all three are isomorphic, and the best candidate is the pair 

. It simply combines the two projections into a pair. In Haskell:

This morphism can also be produced by a factorizing function, again in Haskell:

The coproduct is the reverse of the product, the projections become injections so given an object 

In Haskell, the coproduct is implemented as a datatype called 

Product and coproduct

 object(s) take up the extreme positions in a category.

, with the property that there exists a unique morphism from 

That is the initial object is the object that has a single morphism going from itself to all other objects in the category (including itself). The final object is the object that has a single morphism coming to it from every other object in the category (including itself). The 

Again, as an example, we use the category 

be a singleton set. For each set A there is a unique morphism:

which is the function (in Set) that sends everything to 

. That is, everything in the category ends up as the final object when composed to the extremes.

, which for each set there exists the unique morphism (which exists as from nothing anything can be constructed):

 in Haskell and the unique polymorphic function from 

 (unit) in Haskell and again the unique polymorphic function to 

A category can have both an initial and final object or none, it can have only one, and it can even have more than one initial and/or final objects. More than one initial (or final) objects in a category are isomorphic. This means, that by the definition of inital/final object there can only be one morphism to/from any other object in the category. So take, for example, two initial objects and two unique morphisms between them:

I_1 \xrightarrow {f} I_2
\\
I_1 \xleftarrow {g} I_2

 are isomorphic. A similar argument applies for the terminal objects.

A category in which the initial and final object are the same is said to be a 

. The opposite category is the category in which all the morphisms are reversed.

A \xrightarrow {f} B \xrightarrow {g} C = a \xrightarrow {h} C
\\
h = g \circ f
\\
A \xleftarrow {f^{op}} B \xleftarrow {g^{op}} C = A \xleftarrow {h^{op}} C
\\
h^{op} = f^{op} \circ g^{op}

And as we learned before, there is a morphism 

 that simply selects a value from the type 

select elements of the set without actually having any notion of elements of a set 

Blog

Rest of 2023 update

Meet Pippa

A whole lot of diggin'

Interlude

Combining Maybe and Either monads

First real Haskell project

Natural transformations

Function types

Bifunctors

Functors in Haskell

Functors 101

Product and coproduct

Initial and final object

Monics and epics

Composable things

What is Category Theory?

Peji

helloWorld :: IO ()