Phantom types seem to get used reasonably regularly in a variety of languages for ensuring the safe use of various values (as identifiers, for state transitions and others).

A colleague and I recently found a case where they provided a slightly different benefit. They still helped provide some required type safety, but in this case they also helped to statically associate a value with a generic type parameter, avoiding a runtime lookup and keeping the code succinct using type inference.

This post uses Kotlin, but should be applicable to Java or any other language with generics / parameterised types.

Today I wanted to test a few boolean expressions, and ended up with some quick truth table generation hackery in Haskell which I thought I’d note down for next time. I’m sure there are many better ways of doing this, but this way was mine.

A sordid tale of builds, Gradle, Grunt, node, yarn, Linux, TeamCity, Docker, ssh, and shaven yaks.

Quick reminder to Future Dave, as I’m going to assume he’ll keep making the same mistake Past and Present Daves make.

When switching between my editor and GHCi REPL to test stuff out I often forget to add a deriving (Show, Eq) or similar line to my data types. This normally occurs after I’ve just set up a bit of test data in the REPL, so if I just fix the data declaration and :reload GHCi then my setup will be lost. We can use the StandaloneDeriving GHC extension to help here.

Today I wanted to look at an approach for producing aggregate data from multiple measurements over a source. I’m learning Kotlin at the moment so I’ll use that for the examples in this post, but we can apply the same idea to pretty much any language (I’ve used similar approaches in F#, and it would work with C# albeit with a bit more code noise).

In which I ramble on about how my thoughts on pattern matching have changed over the years.

When I first came across the terms “currying” and “partial application” I was a bit confused about the difference. Here is my attempt at an explanation¹. I’m not 100% confident of my understanding, so please point out any inconsistencies – I’m happy to be corrected :).

C and C-style languages like C++, Java, and C# tend to have method types written like this:

returnType methodName(argType0 arg0, argType1 arg1);

Other typed languages and programming papers use a notation more like this:

methodName : (argType0, argType1) -> returnType

I found it took a bit of getting used to, but I now much prefer to read and write this style. I think it is worth becoming familiar with, as it is used in quite a few languages¹ and in all the programming papers I’ve seen. So here’s a quick guide on how to read this style of type annotation.

I really enjoy trying to understand how and why things like work, but for this post I’m going to try to skip all that wonderful stuff and instead give a practical outline of how to use a very useful pattern arising from applicative functors.

I’ve found this pattern incredibly useful in F#, Swift and Haskell. The examples here are in F#, but as far as I can tell we can use it anywhere that has generic types and higher-order functions.