Jawaninja

Idris Proofs And Nats

2018-02-15T00:00:00+00:00

Idris is a one of those programming languages that empowers its users with the possibility to express very strong guarantees about the code they write before running it. It does this by using something called “Dependent Typing”, which is a very expressive kind of type system.

One of the guarantees you can get is to have safe arithmetic with natural numbers (0, 1, 2, 3…). The interesting bit with Natural numbers is that they cannot be negative, so the substraction a - b only works if b ≤ a. Idris actually forces you to make sure of that before trying to run your code.

Playing around with Nat

Let’s look at some code:

foo : Nat
foo = 4 - 3

Idris will gladly compile, then you can ask the value of foo at the REPL to evaluate the result:

λΠ> foo
1 : Nat

Now if we try another case where a is smaller than b, then idris will not be happy:

foo : Nat
foo = 2 - 3

- + Errors (1)
 `-- fun.idr line 17 col 8:
     When checking right hand side of foo with expected type
             Nat

     When checking argument smaller to function Prelude.Nat.-:
             Can't find a value of type
                     LTE 3 2

So it fails to compile, and tells you it cannot prove that 3 is smaller than 2.

That’s pretty neat! Now how smart is idris then? Let’s try!

foo : Nat
foo = (2 + 2) - 3

Yup! That works! Neat, so Idris can figure out that 2 + 2 ≥ 3 at compile time. Let’s try something harder: can we abstract over one of the parameters?

foo : Nat -> Nat
foo n = n - 3

- + Errors (1)
 `-- fun.idr line 17 col 10:
     When checking right hand side of foo with expected type
             Nat

     When checking argument smaller to function Prelude.Nat.-:
             Can't find a value of type
                     LTE 3 n

Ok so that makes sense: Idris is not happy because it cannot prove that given any natural number n, n is smaller than 3. (for instance, if n = 2 then that’s not true).

But wait…

foo : Nat -> Nat
foo n = (3 + n) - 3

OMG! Yep that compiles! So Idris manages to figure out that given any natural number n, 3 + n ≥ 3! That’s really cool!

It does that just by itself, without me having to prove anything.

How does that work?

Let’s look a bit closer at the - function:

λΠ> :doc (-)
Prelude.Nat.(-) : (m : Nat) -> (n : Nat) -> {auto smaller : LTE n m} -> Nat

    infixl 8

    The function is Total

The first line is the type of the function, and wow, it’s a bit more complicated than I expected… Let’s look at it closer:

(m : Nat) and (n : Nat) are the two arguments to the functions, so we can read (m : Nat) -> (n : Nat) -> ... as “given any natural number m and any natural number n, …”.

The next part is this big thingy: {auto smaller : LTE n m}. Let’s unpack this a bit.

The curly braces {} in the type means it’s an implicit parameter: it’s not passed explicitely, and should be derivable from context. auto is a keyword that tells Idris to automatically derive that parameter from context. So if we removed all that fluff, we could rewrite the type like this:

Prelude.Nat.(-) : (m : Nat) -> (n : Nat) -> (smaller : LTE n m) -> Nat

Which would read like:

Given a natural number m, a natural number n, and a proof “smaller” that n is less than m, you’ll get a natural number out.

The magic happens when adding the curly-braces and the auto keyword, as this proof can be found by Idris automatically.

OK maybe that’s a bit too much… Perhaps the best way is to try to re-implement all of that ourselves from scratch.

Let’s build numbers from scratch

Let’s first define natural numbers. We can define them recursively, by saying it’s either 0 or the successor of another natural number:

data MyNat : Type where
  MZ : MyNat
  MS : MyNat -> MyNat

So 0 is MZ, 1 is MS MZ, 2 is MS (MS MZ)… That’s actually how natural numbers are implemented in idris (using the digits representation is just sugar).

So we can implement addition like this. First we declare the type of addition:

mplus : MyNat -> MyNat -> MyNat

It says “given a natural number and another natural number I’ll give you another natural number”. From that and from your text editor, you can ask Idris to add a placeholder body for the function definition (in emacs, C-c C-s)

mplus : MyNat -> MyNat -> MyNat
mplus x y = ?mplus_rhs

The part with a question mark is what needs to be filled. If you evaluate that code in idris (C-c C-l), Idris will tell you something like this:

Holes

This buffer displays the unsolved holes from the currently-loaded code. Press
the [P] buttons to solve the holes interactively in the prover.

- + Main.mplus_rhs [P]
 `--               x : MyNat
                   y : MyNat
     ------------------------
      Main.mplus_rhs : MyNat

What this says is that there is a “hole” (mplus_rhs) in your program of type MyNat, and that to fill that hole you have 2 parameters at your disposition (x and y) with a similar type. But this doesn’t allow us to define addition, so we can ask Idris to do a case split on the first argument to see if we can get more things at our disposal.

In emacs you do that by putting your cursor on the first argument and pressing C-c C-c, resulting in this:

mplus : MyNat -> MyNat -> MyNat
mplus MZ y = ?mplus_rhs_1
mplus (MS x) y = ?mplus_rhs_2

Which after you load (C-c C-l) you get:

Holes

This buffer displays the unsolved holes from the currently-loaded code. Press
the [P] buttons to solve the holes interactively in the prover.

- + Main.mplus_rhs_1 [P]
 `--                 y : MyNat
     --------------------------
      Main.mplus_rhs_1 : MyNat

- + Main.mplus_rhs_2 [P]
 `--                 x : MyNat
                     y : MyNat
     --------------------------
      Main.mplus_rhs_2 : MyNat

If we look at the first case, the first argument is zero. In that case we just need to return the second argument (0 + y = y). Since nothing is ambiguous here, we can even ask idris to fill that for us by putting the cursor on ?mplus_rhs_1 and performing a “proof search” (pressing C-c C-a):

mplus : MyNat -> MyNat -> MyNat
mplus MZ y = y
mplus (MS x) y = ?mplus_rhs_2

This went like this: when performing the proof search, Idris looked at the type of the hole, and whatever was available from context that matched that type (in this case, only y was available), and used that to fill the hole!

Pretty neat eh?

Now the second bit if we do the same we get the same result:

mplus : MyNat -> MyNat -> MyNat
mplus MZ y = y
mplus (MS x) y = y

Obviously Idris cannot read our mind. If we ask Idris to fill a hole with a given type, it just provides the simple possible answer for that, in this case y.

Fine, let’s just use our human brains. We can use the property that (1 + x) + y = 1 + (x + y):

mplus : MyNat -> MyNat -> MyNat
mplus MZ y = y
mplus (MS x) y = MS (mplus x y)

We can try it out at the REPL:

λΠ> mplus (MS (MS MZ)) (MS (MS MZ))
MS (MS (MS (MS MZ))) : MyNat

λΠ> mplus (MS (MS MZ)) MZ
MS (MS MZ) : MyNat

OK it hurts the eye a little but we can see that 2 + 2 = 4 and 2 + 0 = 2.

Now let’s move to substraction. First the type:

mminus : MyNat -> MyNat -> MyNat

Then add the body automatically:

mminus : MyNat -> MyNat -> MyNat
mminus x y = ?mminus_rhs

Case split on the second argument:

mminus : MyNat -> MyNat -> MyNat
mminus x MZ = ?mminus_rhs_1
mminus x (MS y) = ?mminus_rhs_2

OK x - 0 = x so we can fill the first case:

mminus : MyNat -> MyNat -> MyNat
mminus x MZ = x
mminus x (MS y) = ?mminus_rhs_2

For the second case we need to split again on x actually:

mminus : MyNat -> MyNat -> MyNat
mminus x MZ = x
mminus MZ (MS y) = ?mminus_rhs_1
mminus (MS x) (MS y) = ?mminus_rhs_3

OK last case we can use the fact that (x + 1) - (y + 1) = x - y:

mminus : MyNat -> MyNat -> MyNat
mminus x MZ = x
mminus MZ (MS y) = ?mminus_rhs_1
mminus (MS x) (MS y) = mminus x y

But the middle case is actually annoying: what is the answer to 0 - x for natural numbers? That’s annoying because natural numbers do not contain negative numbers!

So we need to somehow constrain the input in such a way that this case is impossible, i.e. we need to have a proposition that given x and y, y is smaller than x.

Building math from scratch

How do we do that? Actually similarly to how we defined natural numbers:

Any natural number is larger than zero
If n ≤ m, then (n + 1) ≤ (m + 1)

In Idris that translates to something like this:

data MyLTE  : (m : MyNat) -> (n : MyNat) -> Type where
  MyLTEZero : MyLTE MZ right
  MyLTESucc : MyLTE left right -> MyLTE (MS left) (MS right)

So if you want to write 0 ≤ 2, you would write:

zeroLessThanTwo : MyLTE MZ (MS (MS MZ))
zeroLessThanTwo = MyLTEZero

If you want to write 2 ≤ 3, you would write:

twoLessThanThree : MyLTE (MS (MS MZ)) (MS (MS (MS MZ)))
twoLessThanThree = (MyLTESucc (MyLTESucc MyLTEZero))

So MyLTE (MS (MS MZ)) (MS (MS (MS MZ))) is the proposition that 2 ≤ 3, and (MyLTESucc (MyLTESucc MyLTEZero)) is the proof that it’s true.

Given this, let’s start over our definition of minus, this time requiring a proof that m ≤ n:

mminus : (m : MyNat) -> (n : MyNat) -> MyLTE n m -> MyNat

Add body:

mminus : (m : MyNat) -> (n : MyNat) -> MyLTE n m -> MyNat
mminus m n x = ?mminus'_rhs

This time we split on the proof (x):

mminus : (m : MyNat) -> (n : MyNat) -> MyLTE n m -> MyNat
mminus m MZ MyLTEZero = ?mminus'_rhs_1
mminus (MS right) (MS left) (MyLTESucc x) = ?mminus'_rhs_2

Cool! This is where the “dependent type” magic happens: case splitting on the proof has an effect on the arguments m and n: if the proof you provide is 0 ≤ m, then clearly n = 0, and if the proof you provide looks like (1 + x) ≤ (1 + y), then clearly m and n are not zero.

So let’s fill in some of the logic:

mminus : (m : MyNat) -> (n : MyNat) -> MyLTE n m -> MyNat
mminus m MZ MyLTEZero = m
mminus (MS right) (MS left) (MyLTESucc x) = mminus right left ?prf

If we look at the hole left for the proof in the recursive part of this function, we see this:

- + Main.prf [P]
 `--     right : MyNat
          left : MyNat
             x : MyLTE left right
     -----------------------------
      Main.prf : MyLTE left right

There’s a hole of type MyLTE left right and a parameter x of type MyLTE left right! Cool, perhaps we can just ask Idris to fill that up for us! (C-c C-a)

mminus : (m : MyNat) -> (n : MyNat) -> MyLTE n m -> MyNat
mminus m MZ MyLTEZero = m
mminus (MS right) (MS left) (MyLTESucc x) = mminus right left x

Neat!! Now let’s try to use that method a bit:

foo : MyNat
foo = mminus (MS (MS (MS MZ))) (MS MZ) ?prf

This is 3 - 1 with a hole for the proof.

The hole looks like this:

- + Main.prf [P]
 `-- MyLTE (MS MZ) (MS (MS (MS MZ)))

OK… So how do we proceed? Let’s just ask Idris to see if it can figure out something (C-c C-a):

foo : MyNat
foo = mminus (MS (MS (MS MZ))) (MS MZ) (MyLTESucc MyLTEZero)

AAAH! That worked! How is that possible? Actually Idris can try to find proof by looking a the constructors available for the type of the hole (in our case, MyLTEZero and MyLTESucc x) and try to build a value using those constructors.

Neat!

Hide the math!

So can we make that process automatic then? Yes if we introduce the proof as an implicit parameter and add the auto keyword! Let’s try:

mminus : (m : MyNat) -> (n : MyNat) -> {auto smaller : MyLTE n m} -> MyNat

Add the body:

mminus : (m : MyNat) -> (n : MyNat) -> {auto smaller : MyLTE n m} -> MyNat
mminus m n = ?mminus_rhs

Wait… Where’s the proof in the body? OK actually with implict parameters, you have to explicitely say you need them:

mminus : (m : MyNat) -> (n : MyNat) -> {auto smaller : MyLTE n m} -> MyNat
mminus {smaller} m n = ?mminus_rhs

Case split on the proof:

mminus : (m : MyNat) -> (n : MyNat) -> {auto smaller : MyLTE n m} -> MyNat
mminus {smaller = MyLTEZero} m MZ = ?mminus_rhs_1
mminus {smaller = (MyLTESucc x)} (MS right) (MS left) = ?mminus_rhs_2

And fill the rest:

mminus : (m : MyNat) -> (n : MyNat) -> {auto smaller : MyLTE n m} -> MyNat
mminus {smaller = MyLTEZero} m MZ = m
mminus {smaller = (MyLTESucc x)} (MS right) (MS left) = mminus right left

And now we can try again our substraction:

foo : MyNat
foo = mminus (MS (MS (MS MZ))) (MS MZ)

Sweet! And if we do something more funky:

foo' : MyNat -> MyNat
foo' n = mminus (mplus (MS MZ) n) (MS MZ)

Yep that still works! Neato. Wait so how about this:

foo'' : MyNat -> MyNat
foo'' n = mminus (mplus n (MS MZ)) (MS MZ)

- + Errors (1)
 `-- fun.idr line 48 col 17:
     When checking right hand side of foo'' with expected type
             MyNat

     When checking argument smaller to function Main.mminus:
             Can't find a value of type
                     MyLTE (MS MZ) (mplus n (MS MZ))

Ah noes! That didn’t work… The reason for that is that Idris has no idea that 3 + n = n + 3, and we’ve defined addition by case splitting on the first argument…

Well, that’s for another time!

Conclusion

I hope this gave you some idea of how powerful and the kind of guarantees that can be expressed in Idris and gave some insights on how things can be made practical (not having to provide or carry proofs when those proofs can be derived from context).

On Types And Intent

2017-10-29T00:00:00+00:00

I love Clojure and I love Haskell. Those are two of my favourite languages (I also really love Idris). They both offer semantics with very interesting properties and trade-offs.

Sadly there is a disconnect between the communities in both of those languages, where people try to communicate what they like about their favourite language but tend to do that by contrasting it with other languages, and that ends up being quite antagonistic and put people on the defensive.

This is as true of people saying static typing is useless as it is of people saying that dynamically typed languages are recklessly unsafe. It would make life so much easier if either of those statement were true, but sadly we have to deal with the usual grey area.

We also have to acknowledge that we are nowhere near the end of our journey towards understanding information and computation, we don’t even understand our own reality how can we presume knowing how to model it using computers?

Instead of fighting, we should strive together to find a deeper understanding of the principles and trade-off that are involved when writting and evolving code. I would like to make such attempt today by opening a conversation on the communicative power of types.

What’s in a type?

Types are great! They can carry a lot of information if you know what to look for. Let’s look at: foo :: [a] -> [a]. In Haskell, this type says “this is a function from List of a to List of a”. But this tells us so much more than that:

We have no assumptions on a, so we know we’re not transforming the elements of the list.
Since the only assumption we have on the input is it’s a list, that’s the only thing we’re allowed to manipulate. So we can only change its length, ordering and repetitions.
Since there is no IO in the type, the author is communicating that we can assume this function has no side effects.

So there really is not that many functions that satisfies this type. Sadly, there is still an infinity of them:

foo1 :: [a] -> [a]
foo1 x = []

foo2 :: [a] -> [a]
foo2 = tail

foo3 :: [a] -> [a]
foo3 = reverse

foo4 :: [a] -> [a]
foo4 = cycle

foo5 :: [a] -> [a]
foo5 = init

foo6 :: [a] -> [a]
foo6 [] = []
foo6 (x : xs) = foo xs ++ [x] ++ foo xs

foo7 :: [a] -> [a]
foo7 [] = []
foo7 xs@(x : _) = take (length xs) $ repeat x

You get the idea. The types themselves do not communicate all the intent, but they do provide some extra knowledge. I think from the above examples we can agree that intent has to be communicated through some other way (meaningful function names and documentation).

Let’s look at foo7:

foo7 [1,2,3]
-- [1,1,1]

Is the information “we’re not transforming the elements of the list” useful here? In this particular context, not really, even though the shape of the list is the same, its value is very much different. They also have very different runtime properties. Some have constant time, linear time, quadratic time… one of them even being infinitely recursive, which depending on where it’s called can freeze your execution (like in a foldl for instance).

If you want that extra safety of making sure your program will terminate when you compile it, you need a type system that supports totality checking. This is not possible to achieve in the general case (halting problem), but it is for many inductive cases (check Idris if you’re interested). Although note that those checks only guarantee your program will terminate “at some point”, but that point can be 100 years in the future, so it’s still not entirely safe in practice.

There’s another thing: in this case, the implementation is still very much concrete on the type List. If we want to use sets or vectors instead, we have to work at another layer of abstraction. In Haskell, that would be Monoid:

import Data.Monoid

foo8 :: Monoid a => a -> a
foo8 x = mempty

foo9 :: Monoid a => a -> a
foo9 x = x <> x

foo10 :: Monoid a => a -> a
foo10 x = x <> x <> x

We have even fewer assumptions on the input, that’s awesome! However, now that we’re at a higher level of abstraction, the sentence “foo takes as input types that have an instance of the Monoid typeclass and returns values of the same type” both carries more and less information.

Monoid a means the type a contains a value that’s considered the empty element (mempty in Haskell), and an operation on its values (mappend) that can combine them into a value that that also is of type a. They should follow a few special rules (appending the empty value should not change the result for instance), but those rules are not enforced in Haskell, so it does not exactly help our understanding just by looking at the type.

This is an intersting bit of trade-off: the higher abstraction you use (and therefore the fewer assumptions you make), the more general you make your code and the more difficult it is to reason about it without context.

For instance, did you know that functions with monoidal output also form a monoid? So this works:

foo10 (++) [1] [2]
-- [1,2,1,2,1,2]

Also did you know that you can you can form a monoid using numbers? You can have more than one even: the value 0 and addition form a monoid (Sum), and so does the value 1 and multiplication (Product).

So at the REPL, I can ask the type of this expression and it works:

:t foo10 (+) 1 2
-- (foo10 (+) 1 2) :: (Num a, Monoid a) => a

However, because there is more than one possibility for a to be a number and form a monoid, Haskell cannot know which one you mean from the type alone (even though it should be obvious from the value + that we mean the Sum definition). So without more hint, Haskell will not be able to understand what we mean and refuse to compile:

(foo10 (+) 1 2)

<interactive>:82:1: error:
    • Ambiguous type variable ‘a0’ arising from a use of ‘print’
      prevents the constraint ‘(Show a0)’ from being solved.
      Probable fix: use a type annotation to specify what ‘a0’ should be.
      These potential instances exist:
        instance Show All -- Defined in ‘Data.Monoid’
        instance forall k (f :: k -> *) (a :: k).
                 Show (f a) =>
                 Show (Alt f a)
          -- Defined in ‘Data.Monoid’
        instance Show Any -- Defined in ‘Data.Monoid’
        ...plus 30 others
        ...plus 54 instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In a stmt of an interactive GHCi command: print it

So we need to explicitely tell Haskell that we mean the Sum version:

(foo10 (+) 1 2) :: Sum Int
--Sum {getSum = 9}

So it’s really cool that we’re able to express our code in a way that’s at the highest level of abstraction because then we can apply this code in any context that satisfies this abstraction, which is also the downside of it, because then you cannot know in which context that function will be used.

Let’s compare that to a piece of Clojure code:

(reduce + [1 2 3])
;;=> 6

(reduce + [])
;;=> 0

(reduce * [])
;;=> 1

How does that even work? Clojure manages to take advantage of the monoidal properties of + and * over numbers because that knowledge is found at the value level and not at the type level, so there is no ambiguity in the result.

There is an infinite number of monoids on numbers by the way, we can find an easy pattern to generate some of them. The thing is, the mathematical definition of monoid is on a Set (Type) and an Operation (Value). But in Haskell, it is only polymorphic on the Type, meaning you have to create a unique type for each particular monoid. There is an infinite number of Monoids on Lists and Numbers, but you can only represent one of them as “the List Monoid”.

Not saying this is impossible to achieve in a staticly typed language, but you’d have to look at dependent typing intead.

Let’s look at a base case in Clojure:

(defn ++ [a b] (+ a b 1))

(= (++ 1 (++ 2 3))
   (++ (++ 1 2) 3))
;;=> true

(= (++ -1 5) (++ 5 -1) 5)
;;=> true

So we have a base case: addition plus one, with neutral element -1. Fun fact: the empty element for a monoid is implemented as the zero arity for a function. This is purely conventional. Obviously that’s also not general: it means a given function can only be monoidal in one domain (numbers in the case of addition and multiplication).

Anyway, let’s write a monoid generator given this information:

(defn add-n-monoid [n]
  (fn ([] (- n))
      ([a b] (+ a b n))))

(def ++1 (add-n-monoid 1))
(def ++2 (add-n-monoid 2))
(def ++3 (add-n-monoid 3))

(= (++1 1 (++1 2 3))
   (++1 (++1 1 2) 3))
;;=> true

(= (++1 (++1) 5) (++1 5 (++1)) 5)
;;=> true

Yay, infinite number of monoids!

(reduce ++3 [])
;;=> -3

(reduce ++3 [1 2 3 4])
;;=> 19

Anyway, you can use runtime polymorphism in Clojure to have monoids that are closer to their mathematical definition, the downside is that you can’t know beforehand if the reducer is monoidal or not, so you get a runtime error here instead:

(reduce - [])
;;!! ArityException Wrong number of args (0) passed to: core/-

That doesn’t mean we’re stuck, that just means we can’t rely on the monoidal “neutral element”, we need to pass the initial value explicitely:

(reduce - 0 [])
;;-> 0

(reduce - 0 [1 2 3])
;;-> 6

The trade-off here is: I can think about those things in category-theory terms, and I don’t have to impose this thinking on people around me (and in particular beginners). But the downside is I’m not helped by the language out of the box to follow those rules.

To me that’s some interesting trade-off to think about!

How many assumptions do we make?

Haskell is pure by convention. This convention is enforced to some extent by the type system, but you can always bypass it and do weird stuff. Let’s define this interesting piece of code:

import System.IO.Unsafe

foo11 :: Int
foo11 = unsafePerformIO $ do
          print "yo"
          return 11

If we call it, it will print "yo" then return 11 the first time around, and the second time will only return 11 and not print anything.

foo11
--~ "yo"
-- 11

foo11
-- 11

Mind you, this is not a bad thing! Having side-effects internally does not necessary mean having visible side-effects globally. Memoization for instance is a useful “side-effect”, Haskell does that as a runtime optimisation (like we see with foo11). Or transient datastructures can me mutated in place to speed things up within the context of a pure function that returns the immutable version of that datastructure, and it makes sense because performance is important.

You might say “Ha! but you’re importing System.IO.Unsafe so we know you’re doing funky stuff!”, and you’d be right: if you look at the code, you get more info about its behaviour. But we’re only interested at how much information the type annotations contain, not the code.

Clojure chooses to be immutable by default, but does not try to completely isolate side-effects. However it would not be fair to consider all Clojure code to be as if implicitly inside an unsafePerformIO!

Why is that? Because Haskell relies on the knowledge that a function is pure to perform all sorts of optimisations, which is really good for performance. Like in our code above, it chooses to memoize the execution of foo11 because its type signature says it’s pure. This behaviour is implicit and happens at the compiler level. You’d have to express that explicitly in Clojure:

(def foo11
  (memoize
   (fn []
    (println "yo")
    11)))

Given there is no built-in type annotation in Clojure, what am I getting at? Well the “type” information is implicit, and much weaker than with Haskell, but the convention is stronger than other languages that are not immutable by default. You can most of the time assume the inputs are immutable, and are either a value or a collection of values.

“Most of the time”, “assume”… This doesn’t sound very safe does it? The thing is, even though it’s not obvious, we have to “assume” and “most of the time” in Haskell as well. We have to assume that the implementation of Monoid follows its associative and neutral element laws, and that our code does not contain non-lazy infinite recursions… At best, we can verify them through testing. Of course this is not true with dependent typing and Idris, but even with the state of the art you always end up drawing a line somewhere in practice.

The interesting question (to me) is: how much should we assume and how often? Where do you draw the line for a given context?

Convention dominates information

This is what I’m getting at with this conversation.

There’s a point where convention dominates information, otherwise you get to an infinitely high level of abstraction in turn requiring an infinite amount of context.

Where this point lies is the core of the debate. My position is that the conventions enforced statically at the type level by languages like Haskell are not necessary nor sufficient and come at a non-zero cost. Whether that cost is higher than the value provided is debatable, but the fact that it comes at a cost should not be controversial. Understanding the cost / value proposition of static typing is really important to me.

You can look at the fact that Ruby on Rails has been such a success and come to the conclusion that this success was only due to some Pop Culture effect or random chance. But what it did was provide a set of conventions that were super efficient and was able to communicate those conventions somehow, thus pushing the industry forward.

On means of communication

Here are some of the means to communicate intent when writting code:

function and argument names
documentation
type and contract annotations
the code itself

If we look purely at the communicative power of what we write, the code itself is it: it’s literally the definition of what we mean. However, it’s not convenient to read code, so the question is what do we use to make our life easier and our understanding quicker?

The answer is dependent on the abstractions available in the language we use: how many particular cases do we need to keep in mind at all time?

Haskell has the following approach: there is an infinite amount of abstractions that are expressible in the type system so that you don’t have to keep track of all of them in your head.

Clojure has the following approach: there is a very small amount of abstractions, so that you can keep all of them in your head.

Those two approaches require two different kinds of communication. If you have a very small set of abstractions, you can easily keep all of them in your head and apply them in your understanding of your code. If you have an infinite amount of abstractions, then you want as much help from the language as you can to not have to juggle all of them in your head, and type information becomes paramount. But beware that this can be a self-fulfilling profecy: you need an infinite amount of types to deal with infinite abstractions, and infinte abstractions require an infinite number of types.

So the end of the Haskell (PureScript, Idris…) journey is an asymptotic one: values and types evolve towards a meta-circular answer that’s extremely close to the essence of mathematics and phylosophy. It’s an awesome journey by the way, I personally needed to step into the realm of dependent typing to begin to get an intuition about this.

I digress a bit: my point is that if your goal is many abstractions, your solution will require a lot of communication.

But infinite abstraction and infinite reuse is not one of my personal goal. What I care about is producing things as fast and reliably as I can, and the 80/20 pareto rule is my guide in any decision I make.

As an engineer, if my solution is perfect then I wasted too many resources in making it perfect. I want to find the most cost-efficient way to implement something.

How much can I sacrifice to reach my goal?

What’s the minimum I need to communicate my intent and get it out there? Code.

This is my personal preference and not everyone might agree with this priority, but if there is a case where I want to move as fast as possible, I want to be able to take risks and try to get it out there. Sometimes, if there is a 1 out of 10 chance of succeeding, I want to take that chance, and that might mean sacrificing all other benefits for short term gain.

Sometimes being forced to think of all the edge-cases upfront is exactly what I need: when implementing a protocol or a parser or things like that, I want all the help I can with dealing with a million abstractions, because those abstractions are pushed onto me. So I’m not being dismissive of that use case.

But (most of the time) I want to work with a very small set of abstraction and just make the simplest thing that can possibly work without thinking about any of the edge cases. I might get a runtime error, but the code will work 90% of the time and that will be good enough for me to sell my product, adapt to a new market, who knows.

Having a type system that forces me to think about those edge cases works against this stated goal. It forces me to be correct above all, but this is not what I want: I want to have the happy path solved as fast as possible, and I’ll handle the edge cases as they show up over time.

I also want the ability to add all those niceties and guarantees to my code, but I want the freedom to take risks.

Now how can I have my cake and eat it too? In order to have maintainable code, you need runtime tests (to make sure that the runtime properties of your project hold). Some of those tests can be replaced by static typing.

Now the question is: is the cost of having static types (in terms of rigidity, numbers of abstraction and required context) lower than maintening a test suite for the guarantees covered by those types?

In the case of Clojure vs Haskell specifically (both of which have immutable data, namespacing, explicit side-effects, static name resolution), both approaches seem empirically equivalent in my experience, so I favor the one that is objectively “smaller” (fewer abstractions, smaller context).

You can always compare Clojure to Java/C++ and Haskell to JavaScript/Python, and they would come out obviously winning.

You can also compare Clojure to JavaScript/Python and Haskell to Java/C++, and they would also be winning.

That’s not how euclidian distance works though, those are not very useful comparison.

How do I communicate intent?

The first step to good communication is finding meaningful names.

This is very much necessary anyway because the first step of implementing something is understanding the domain of that thing, and understanding the domain is all about naming things.

Same with documentation: documentation is part of understanding the domain itself, and has value beyond the understanding of the code.

Also finding some examples, that really helps with understanding. Those examples can be written as tests so that they can allow you to verify your code.

Verification is a nice tool: it does not guarantee anything, but it allows you to check some of your assumptions. And you do need to verify your code, and that means writting tests.

Finally, type and contract annotation help with the boundaries of your code. Those allow to not only communicate the API between your functions, but also make sure that information is kept in sync with the code.

All of the above require constant maintenance. You might believe none of them should be negociable, but I believe they all are: for your given domain, you have to establish the cost and value of each of those, and decide if you want to invest in them upfront or only after you’re successful.

In some cases, the code itself is not even the most important, and the documentation and types are everything! And sometimes, only the artefact you’ve created matters.

What do I care about right after “it works”?

Beyond communicating intent, verifying and proving things, there are many other considerations I have in mind:

Will it run fast enough?
Will it scale?
Will it run out of memory?
Am I using the right datastructure?

And so many other considerations. In my experience, those answers are easier to find in a language with a clear set of datastructure and a list of functions on those datastructure that have consistent runtime properties.

It is also much easier in a language that does not abstract over its runtime.

It is not impossible to express and have guarantees about those properties in a type system. In fact, Linear types have just been added to the Haskell compiler to communicate some of those. And it’s super neat! I love that. It’s just that you NEED those in order to get an understanding of runtime properties when running at this level of abstraction, because otherwise you simply can’t wrap your head around it.

Look I love those! I really really enjoy this, and I know this, but as an engineer I want to be able to make sacrifices and trade-offs to get imperfect solutions out, because imperfect solutions are the cheapest to produce.

Engineering and Science

We need Computer Science. But we also need Computer Engineering. We need to understand what “the minimum requirement” for a solution is, what constraints we can relax and what kind of risks we’re taking.

We can’t throw around terms like “correctness” or “freedom” without understanding what they mean and their cost.

Too often the conversation ends up being “you don’t like types because you don’t know enough types”, or “types is only for academia and is always standing in my way”. But I hope we can find an place where someone doesn’t have to either prove they know Profunctor Optics or avoid using precise mathematical terms before their approach to software engineering is taken seriously.

Disclaimer: what do I know about the subject?

Here is a bit of info about me. Those are some of the things I have played with and have investigated the trade-offs of in the context of functional programming. I’m sharing this list because I find the topic fascinating and I like to understand trade-offs:

parametric polymorphism (Haskell, PureScript) vs ad-hoc polymorphism (Clojure) vs subtyping (Clojure, OCaml)
dynamic typing (Clojure) vs gradual typing (Racket, Clojure + core.typed) vs static typing (Haskell, PureScript, Elm)
dependent typing (Haskell, Idris)
verification (Promela) vs proof (Idris, Agda)

Those trade-offs include soundness, verification, proofs, inference (type or code!), runtime properties, expressivity…

All those aspects and tools are super interesting and useful when applied in the right context. But there is no general best solution or programming language, because you need to define fitness in your context first. Also I encourage you to explore all those axis and more! But above all, please explore beyond the one axis you’re familiar with.

Conclusion

I have a million more things to express, but the gist of what I’m trying to say is: let’s not conflate good software engineering practices (or functional programming for that matter) with just static typing, and let’s not dismiss it either. Even static verification should not be mistaken with or limited to static typing. Doing so goes against the very essence of engineering. State your constraints, assumptions and objectives first, and consider Static Typing as a tool, not an end in itself.

Asymptotically approaching an answer that’s forever out of reach in the pursuit of truth: that’s Science.

Finding the smallest and cheapest thing that can possibly work: that’s Engineering.

The two are completing each other and should be considered in harmony, not conflict.

Functional Programming... The Sequel

2017-03-01T00:00:00+00:00

Event page: https://www.meetup.com/ReactJS-Goteborg/events/236379075

Slides available here: https://github.com/Jell/intro-to-fp

Intro to Functional Programming

2016-11-22T00:00:00+00:00

Event page: https://www.meetup.com/ReactJS-Goteborg/events/235335371/

Slides available here: https://github.com/Jell/intro-to-fp

A Tale of ClojureScript in Production

2016-10-25T00:00:00+00:00

Euroclojure 2016: http://2016.euroclojure.org/

My slides: https://github.com/Jell/euroclojure-2016

The Way I Understand Types

2014-10-11T00:00:00+00:00

This is my current intuition on types. I heard the best way to get feedback on the internet is to publish something inaccurate, so there you have it.

What is a Type?

Types are sets of properties held by values. In a language, the more things you have that are values, the richer your types are.

Values can have many sorts of properties: all values that are numbers can be added together, all values that are strings can be concatenated, all values that are functions can be invoked.

A type could be for instance “all values that are printable”. Or even “all values that are values”. One could even devise a type that cannot contain any value, i.e “all values that are not values”.

A type is large if many values belong to it, and is small when few do. The larger the type, the smaller the sets of properties it represents.

The largest type a value can have is the type of having no particular property, so all values belong to it, whereas the smallest type is the type of having all the imaginable properties at once, which is impossible so no value can belong to it.

A value can have many properties: “3” is a value, a number, a representable value, and it has the value “3”.

So we could say that “3” is of type Value, Number, Representable, and BeingTheNumber3.

What do we use types for?

Dispatching

We need to dispatch on those types at some point if we want to manipulate values in our program.

One way to go is to keep all that information in the value itself, and do a so-called dynamic dispatch: at runtime, simply look at the value and see what properties it has. If it is missing the property you need, well that’s a so-called type error.

Another way to do that is to do a static dispatch. A program is made of variables that when running will hold values. They are called variables because over time they will hold different values. A variable has the type of the union of the types of all the values it can hold at runtime.

What this means is that a variable can have the properties of all the values it can hold, but not necessarily all at once.

We can annotate those variables before running our program (i.e statically) with their smallest type, that is the set of property we believe they will always hold at any given time later on when we actually run the program.

By doing so, we can use the proper implementation for a given variable without having to look at the value it is holding at runtime, so we no longer need to encode this property on the value itself.

Verifying

If we have annotated a variable with a given type, but pass on a value with another type, we get a type error and unexpected behavior.

We can improve our static dispatch approach by actually proving that each variable will only hold values that share its assumed properties, i.e are of the same type. This requires implementing a type checker that can reflect on the invariances of our program and infer the types of each variable without running it.

If a unification fails, we get an error. By verifying a program with a type checker, we can get rid of all the type errors involving all the types that are expressible and used in our program. This could be for instance that no matter what, we only fetch the first element on non-empty lists, or that we always add vectors of the same length. Types can express arbitrary invariances, as long as the language can express them and the compiler can prove their veracity.

To be noted, using dynamic dispatch does not preclude having a type checker. By having proper annotations, we can still reflect on the invariances of our program, even if that knowledge is not necessarily used at runtime (see Gradual Typing, as with Clojure’s core.typed).

Not all types are easily expressible and/or easy to reason about. And proving that certain invariances are held can be computationally very expensive, if possible at all. But the more is expressed in the type system, the less can go wrong at runtime.