Big props to Diplo

Coldplay’s ‘42’ from Viva la Vida or Death and All His Friends (starting about 1:45), Nine Inch Nails ‘Complication’ from The Fragile.

Update: Fleet Foxes ‘Quiet Houses’ does this even more.

A Comparison

Firstly, I’ll show a short comparison between some Java code and some code from a language that doesn’t have NullPointerExceptions, but does have something that allows you to accomplish anything you might want to do with null pointers.

This Java code:

AnObject thing = someMethod();

is equivalent to the following Haskell:

let thing = Maybe AnObject

That is, every Java object reference is possibly null. What this means is that (using the type notation mentioned in earlier posts) every Java reference has the type:

(Every object reference for an object is either to ‘null’ (AKA ‘unit’ or ‘singleton’, or the object itself.)

… and when you’re dealing with so many objects—Java is, after all, an object-oriented language, so (almost) everything is an object—this simple little “+1″ gets lost easily.

Why so bad?

This wouldn’t seem to be such a big deal, but when contrasted against Java’s penchant for making things (sometimes painfully) explicit—think public static void main (string argh!)—a small, implicit item like this is easily overlooked. Conversely, one might say that the verbosity of Java increases the cognitive load of understanding its code; thus helping the chances of a small mistake like this sneaking through.

Either way, I think I can say that this is objectively A Bad Thing. C# has gone some of the way to a ‘correct’ solution in its introduction of possibly-null primitives, which are explicitly marked with a ? (such as int?), but unfortunately this hasn’t been ‘back-ported’ to the rest of the language. If one were able to force between possibly-null and definitely-not-null references in C#—perhaps by the analogous object? vs. object, this would help to reduce the number of errors ‘hidden’ by the syntax.

data Surreal = Zero | Plus Surreal | Minus Surreal

… which also seems very similar to the usual construction for natural numbers:

data Nat = Zero | Succ Nat

(I noted this in a comment on the original post.)

This got me thinking about how this construction (the sign-expanded version) mapped onto the original construction of the surreal numbers, which uses a left and a right set:

data Surreal = Surreal [Surr] [Surr]

These types translate to the following (in order of appearance):

This last type is suggestive for the natural numbers as well, and of course there is a analogous construction for the naturals:

…which is a set-based construction for the naturals. (Note that in the above formulas multisets are used instead of true sets, but I don’t think this makes a difference in this context.)

Of course this raises the question of what is possible with three sets (or a 3-enum (3-num?)). More on this in another post.

T[X] = Forall(n : N) Xn / Autn

This is a little much for me, since I don’t understand the symbolism and terminology used in the other 99% of the paper, either! However, as they note that it closely matches the Taylor-series expansion of e^x. I think that using the simple concepts I linked to in the previous post, I can approach a similar definition.

First of all, start with a simple (identity?) type:

F[X] = X

Now, since what we want is a type that when differentiated, gives itself, we should start by integrating:

F[X]  = X2 ÷ 2

As shown in the previous post, we can interpret the division operator as ‘missing information’. In this case, the missing information is a 2-enum stating where the new type element was to be inserted… thus we have a type consisting of two elements, only we don’t know in what order they should appear. If we repeat this process several times, we obtain:

F[X] = X3 ÷ (2×3)
F[X] = X4 ÷ (2×3×4)
F[X] = X5 ÷ (2×3×4×5)

Now we can begin to see a pattern emerging. Each time we integrate the function, we are adding an element to the type, without saying where it should be inserted—in other words, we are creating an unordered set of objects (note that these aren’t true sets, but merely bags: sets which can contain duplicates). Now if we take the literal Taylor expansion of e^x, we can see what it really is as a type:

E[X] = Σ (Xn ÷ n!)

It is either a bag with one element, or a bag with two elements, or a bag with three elements… it is in fact the union of all bag types! That is, the exponential function interpreted as a type, is the type of bags.

If we take integration to be the logical inverse of differentiation (which is defined in the article as ‘removal of an element from a type’, then we have integration as the addition of an element to a type.

For example, take the type of an array of 3 elements of the same type:

F[T] = T3

If we are to add an element to this array, we want to integrate it. This gives us:

F[T] = T4 ÷ 4

Clearly this is not what we expected. If we want to add an element to a 3-element array, we are expecting a 4-element array. However, if we look again at the above result, we can reinterpret it as telling us something: the mere integration of the type is not supplying the expected result; and if we interpret division as ‘without’ (just as addition is ‘or’ and multiplication is ‘and’, then we can understand the result obtained.

What this is in fact telling us is that we need to provide another parameter (an enum in this case), which will give us the required result. In other words (if we do it backwards…:

F[T] = T4 -- wanted
F'[T] = 4.T3 -- needed

In order to obtain a 4-element array, we need a 3-element array and a 4-enum. This makes sense, because if we have a 3-element array:

x y z

…and we wish to add an element ‘w’ to it, we need to know where to insert it. The number of insertion points is:

(1) x (2) y (3) z (4)

…and thus we need to supply a 4-enum to specify exactly where we want the insertion to take place. Once we have done this, we obtain our 4-element array with no ‘missing’ parameters.

foldr getCounts (0,0,0) $ map classify $ concat [[20..30], [490..500], [8120..8130]]

In order to understand what is happening here, one needs to start from the RHS of the expression and then work backwards—much the same as in this snippet of APL:

(∼R∈R∘.×R)/R←1↓⍳R

(See the Wikipedia article on APL for what is happening here.)

In both cases, the code is operating upon a common parameter which is modified by each function in turn. Similarly, there seems to be a rather high-level isomorphism between these kinds of functional code and the concept of Unix pipes:

sort file | uniq -c | sort -n

…with the difference being that in this case, the common parameter is being passed from the left instead of from the right.

Now, in Haskell I can define a new “pipe” operator (| is already taken):

(~>) :: a -> (a->b) -> b
(~>) x f = f x

Which just has the reverse signature to the $ operator, and:

foldr getCounts (0,0,0) $ map classify $ concat [[20..30], [490..500], [8120..8130]]

…becomes…

[[20..30], [490..500], [8120..8130]] ~> concat ~> map classify ~> foldr getCounts (0,0,0)

…which makes it a bit easier to read, at least in my (used-to-Linux) eyes.