Recently, Erica Sadun wrote about inconsistencies in Swift’s function-like constructs, such as KeyPath and method references—a post that appears lost in the apocalypse befalling her site.

Erica pointed out that method references return (A) -> () -> B functions that aren’t directly useable by higher order functions like map, which takes an (A) -> B function.

// Basic example
["a", "b"].map { "a".uppercased() } // ["A", "B"]

// Using a method reference. Hmm. Not quite what we wanted
["a", "b"].map(String.uppercased) // [() -> String, () -> String]

// Junky alternatives
["a", "b"].map(String.uppercased).map { $0() }
["a", "b"].map { String.uppercased($0)() }

She then works through a couple of solutions. A custom map style function on Sequence taking such a function and hiding the extra function application, and eventually an apply function that converts (A) -> () -> B to (A) -> B (and an accompanying operator).

One thing that struct me was how Erica derived all this from first principles, essentially reimplementing a function called flip, a common function in functional programming circles. From my perspective I immediately saw the problem as:

Oh, I need to flip this function and partially apply it to ()

Unfortunately, because we’re using Swift, it’s not quite that easy.

func flip<A, B, C>(f: (A) -> (B) -> C) -> (B) -> (A) -> C {
    return { b in { a in f(a)(b) } }
}

// Doesn't compile! For a couple of Swiftastic reasons.
["a", "b"].map(flip(String.uppercased)())

Swift treats () parameters as a special case, not just another type, so () can not be used as a B. Let’s write a special case version:

func flip<A, B>(_ f: @escaping (A) -> () -> B) -> () -> (A) -> B {
    return { { a in f(a)() } }
}

// This one does compile! Though you may notice it looks to have some redundancy.
["a", "b"].map(flip(String.uppercased)())

And we can now reimplement Erica’s apply in terms of our special case of flip:

func flap<A, B>(_ f: @escaping (A) -> () -> B) -> (A) -> B {
    return flip(f)()
}

["a", "b"].map(flap(String.uppercased))

Or just remove the intermediary special case of flip altogether, arriving at exactly Erica’s solution (operator not withstanding):

func flap<A, B>(_ f: @escaping (A) -> () -> B) -> (A) -> B {
    return { a in f(a)() }
}

["a", "b"].map(flap(String.uppercased))

In the end, we’ve arrived at the same solution to this specific problem. However, I hope I’ve illustrated how viewing programming from a slightly different perspective let us identify the issue quickly, and build a solution out of existing smaller, composeable pieces.

Sometimes my spheres of interest overlap.

Meeting Matt Carter at OzTek a couple of years ago, and working with Pim Bongaerts on mesophotic.org introduced me to photogrammetry, and over the past few weeks I’ve been processing some models using 4K video.

Selecting useable still frames is tedious at best: manual selection is a non starter, and basic selection with ffmpeg often produces blurred frames.

I solved this with framer.sh, a script for selecting better frames.

Feel free to use and improve it. Pull requests accepted.

Recently, Brandon Williams posted Algebraic Structure and Protocols, a great article describing and building semigroups, monoids and groups using Swift protocols. It’s an interesting article and I encourage you to read it (and his other articles). In fact, I’ll wait while you do…

As with most such articles there are some simple examples, however I find the leap from ok, I see what that is, to oooooh, I see what this thing does! somewhat confounding.

In other words, how do I spot this pattern and use the technique in my own code?

I aired this small grievance, wondering if mconcat([1,2,3,4]) was just a fancy way to replace reduce([1,2,3,4], 0, +)¹ in my code? In response, Nick Partridge said yes, but related the following real example from his work:

I am measuring outdoor advertising views. I have many different Collectors of this metric for various types of signage with a type like: Trip -> ViewCount. e.g. A collector of views for buses seen along the trip or a collector of views for billboards. These are all independent things that I need to collate.

This example was a penny drop moment for me. The Collector type is a monoid!

Given a specific trip, the idea is to calculate the view counts for different types of signage and collate them in some way. It doesn’t really matter what way. Maybe we’re adding them all together for a total, maybe we’re returning a list of counts, or a dictionary of types and counts. It doesn’t matter. We’re taking a list of Collectors and a Trip to process, and returning some collation of the data.

We can process this manually, of course. We can take our list of Collectors, pass the Trip to each, get the results, then collate them however we want.

But if we recognise this as a monoid, we realise that a lot of that code is already written, it’s the same code that processes all our other monoids. A tiny abstraction that is common to a lot of things. We already know how to collate things. We give their type a collation operator and an identity, then mconcat them.

In other words, we can mconcat our Collectors and produce a new composite Collector that does the collating for us. We can pass our Trip to that new Collector and obtain our result directly. For example, instead of something like:

let collectors = [collector1, collector2]
var result: Int
for collector in collectors {
    result = result + collector(trip)
}

we can take a small step to this:

let collectors = [collector1, collector2]
collectors.map { collector in collector(trip) }.reduce(0, +)

but once we’ve defined a monoid extension for Collector, we can:

let collate = mconcat([collector1, collector2])
collate(trip)

We have abstracted away the idea of how we’re going to collate our data and instead ask for collated results directly. How to define this monoid is actually covered in Exercise 6 of Brandon’s article.

Semigroups, monoids and groups while perhaps alien, are in fact useful and common. They’re names for patterns we encounter frequently and now recognise. Maybe you’re like me and have just realised you’re working on something monoidal right now.