Eli Bendersky's website - Haskell

Type inference

2018-11-14T06:16:00-08:00

Type inference is a major feature of several programming languages, most notably languages from the ML family like Haskell. In this post I want to provide a brief overview of type inference, along with a simple Python implementation for a toy ML-like language.

Uni-directional type inference

While static typing is very useful, one of its potential downsides is verbosity. The programmer has to annotate values with types throughout the code, which results in more effort and clutter. What's really annoying, though, is that in many cases these annotations feel superfluous. Consider this classical C++ example from pre-C++11 times:

std::vector<Blob*> blobs;
std::vector<Blob*>::iterator iter = blobs.begin();

Clearly when the compiler sees blobs.begin(), it knows the type of blobs, so it also knows the type of the begin() method invoked on it because it is familiar with the declaration of begin. Why should the programmer be burdened with spelling out the type of the iterator? Indeed, one of the most welcome changes in C++11 was lifting this burden by repurposing auto for basic type inference:

std::vector<Blob*> blobs;
auto iter = blobs.begin();

Go has a similar capability with the := syntax. Given some function:

func parseThing(...) (Node, error) {
}

We can simply write:

node, err := parseThing(...)

Without having to explicitly declare that node has type Node and err has type error.

These features are certainly useful, and they involve some degree of type inference from the compiler. Some functional programming proponents say this is not real type inference, but I think the difference is just a matter of degree. There's certainly some inference going on here, with the compiler calculating and assigning the right types for expressions without the programmer's help. Since this calculation flows in one direction (from the declaration of the vector::begin method to the auto assignment), I'll call it uni-directional type inference [1].

Bi-directional type inference (Hindley-Milner)

If we define a new map function in Haskell to map a function over a list, we can do it as follows:

mymap f [] = []
mymap f (first:rest) = f first : mymap f rest

Note that we did not specify the types for either the arguments of mymap, or its return value. The Haskell compiler can infer them on its own, using the definition provided:

> :t Main.mymap
Main.mymap :: (t1 -> t) -> [t1] -> [t]

The compiler has determined that the first argument of mymap is a generic function, assigning its argument the type t1 and its return value the type t. The second argument of mymap has the type [t1], which means "list of t1"; then the return value of mymap has the type "list of t". How was this accomplished?

Let's start with the second argument. From the [] = [] variant, and also from the (first:rest) deconstruction, the compiler infers it has a list type. But there's nothing else in the code constraining the element type, so the compiler chooses a generic type specifier - t1. f first applies f to an element of this list, so f has to take t1; nothing constrains its return value type, so it gets the generic t. The result is f has type (t1 -> t), which in Haskell parlance means "a function from t1 to t".

Here is another example, written in a toy language I put together for the sake of this post. The language is called microml, and its implementation is described at the end of the post:

foo f g x = if f(x == 1) then g(x) else 20

Here foo is declared as a function with three arguments. What is its type? Let's try to run type inference manually. First, note that the body of the function consists of an if expresssion. As is common in programming languages, this one has some strict typing rules in microml; namely, the type of the condition is boolean (Bool), and the types of the then and else clauses must match.

So we know that f(x == 1) has to return a Bool. Moreover, since x is compared to an integer, x is an Int. What is the type of g? Well, it has an Int argument, and it return value must match the type of the else clause, which is an Int as well.

To summarize:

The type of x is Int
The type of f is Bool -> Bool
The type of g is Int -> Int

So the overall type of foo is:

((Bool -> Bool), (Int -> Int), Int) -> Int

It takes three arguments, the types of which we have determined, and returns an Int.

Note how this type inference process is not just going in one direction, but seems to be "jumping around" the body of the function figuring out known types due to typing rules. This is why I call it bi-directional type inference, but it's much better known as Hindley-Milner type inference, since it was independently discovered by Roger Hindley in 1969 and Robin Milner in 1978.

How Hindley-Milner type inference works

We've seen a couple of examples of manually running type inference on some code above. Now let's see how to translate it to an implementable algorithm. I'm going to present the process in several separate stages, for simplicity. Some other presentations of the algorithm combine several of these stages, but seeing them separately is more educational, IMHO.

The stages are:

Assign symbolic type names (like t1, t2, ...) to all subexpressions.
Using the language's typing rules, write a list of type equations (or constraints) in terms of these type names.
Solve the list of type equations using unification.

Let's use this example again:

foo f g x = if f(x == 1) then g(x) else 20

Starting with stage 1, we'll list all subexpressions in this declaration (starting with the declaration itself) and assign unique type names to them:

foo                                       t0
f                                         t1
g                                         t2
x                                         t3
if f(x == 1) then g(x) else 20            t4
f(x == 1)                                 t5
x == 1                                    t6
x                                         t3
g(x)                                      t7
20                                        Int

Note that every subexpression gets a type, and we de-duplicate them (e.g. x is encountered twice and gets the same type name assigned). Constant nodes get known types.

In stage 2, we'll use the language's typing rules to write down equations involving these type names. Usually books and papers use slightly scary formal notation for typing rules; for example, for if:

\[\frac{\Gamma \vdash e_0 : Bool, \Gamma \vdash e_1 : T, \Gamma \vdash e_2 : T}{\Gamma \vdash if\: e_0\: then\: e_1\: else\: e_2 : T}\]

All this means is the intuitive typing of if we've described above: the condition is expected to be boolean, and the types of the then and else clauses are expected to match, and their type becomes the type of the whole expression.

To unravel the notation, prepend "given that" to the expression above the line and "we can derive" to the expression below the line; \Gamma \vdash e_0 : Bool means that e_0 is typed to Bool in the set of typing assumptions called \Gamma.

Similarly, a typing rule for single-argument function application would be:

\[\frac{\Gamma \vdash e_0 : T, \Gamma \vdash f : T \rightarrow U}{\Gamma \vdash f(e_0) : U}\]

The real trick of type inference is running these typing rules in reverse. The rule tells us how to assign types to the whole expression given its constituent types, but we can also use it as an equation that works both ways and lets us infer constituent types from the whole expression's type.

Let's see what equations we can come up with, looking at the code:

From f(x == 1) we infer t1 = (t6 -> t5), because t1 is the type of f, t6 is the type of x == 1, and t5 is the type of f(x == 1). Note that we're using the typing rules for function application here. Moreover, we can infer that t3 is Int and t6 is Bool because of the typing rule of the == operator.

Similarly, from g(x) we infer t2 = (t3 -> t7).

From the if expression, we infer that t6 is Bool (since it's the condition of the if) and that t4 = Int, because the then and else clauses must match.

Now we have a list of equations, and our task is to find the most general solution, treating the equations as constraints. This is done by using the unification algorithm which I described in detail in the previous post. The solution we're seeking here is precisely the most general unifier.

For our expression, the algorithm will find the type of foo to be:

((Bool -> Bool), (Int -> Int), Int) -> Int)

As expected.

If we make a slight modification to the expression to remove the comparison of x with 1:

foo f g x = if f(x) then g(x) else 20

Then we can no longer constrain the type of x, since all we know about it is that it's passed into functions f and g, and nothing else constrains the arguments of these functions. The type inference process will thus calculate this type for foo:

((a -> Bool), (a -> Int), a) -> Int

It assigns x the generic type name a, and uses it for the arguments of f and g as well.

The implementation

An implementation of microml is available here, as a self-contained Python program that parses a microml declaration and infers its type. The best starting point is main.py, which spells out the stages of type inference:

code = 'foo f g x = if f(x == 1) then g(x) else 20'
print('Code', '----', code, '', sep='\n')

# Parse the microml code snippet into an AST.
p = parser.Parser()
e = p.parse_decl(code)
print('Parsed AST', '----', e, '', sep='\n')

# Stage 1: Assign symbolic typenames
typing.assign_typenames(e.expr)
print('Typename assignment', '----',
      typing.show_type_assignment(e.expr), '', sep='\n')

# Stage 2: Generate a list of type equations
equations = []
typing.generate_equations(e.expr, equations)
print('Equations', '----', sep='\n')
for eq in equations:
    print('{:15} {:20} | {}'.format(str(eq.left), str(eq.right), eq.orig_node))

# Stage 3: Solve equations using unification
unifier = typing.unify_all_equations(equations)
print('', 'Inferred type', '----',
      typing.get_expression_type(e.expr, unifier, rename_types=True),
      sep='\n')

This will print out:

Code
----
foo f g x = if f(x == 1) then g(x) else 20

Parsed AST
----
Decl(foo, Lambda([f, g, x], If(App(f, [(x == 1)]), App(g, [x]), 20)))

Typename assignment
----
Lambda([f, g, x], If(App(f, [(x == 1)]), App(g, [x]), 20))   t0
If(App(f, [(x == 1)]), App(g, [x]), 20)                      t4
App(f, [(x == 1)])                                           t5
f                                                            t1
(x == 1)                                                     t6
x                                                            t3
1                                                            Int
App(g, [x])                                                  t7
g                                                            t2
x                                                            t3
20                                                           Int

Equations
----
Int             Int                  | 1
t3              Int                  | (x == 1)
Int             Int                  | (x == 1)
t6              Bool                 | (x == 1)
t1              (t6 -> t5)           | App(f, [(x == 1)])
t2              (t3 -> t7)           | App(g, [x])
Int             Int                  | 20
t5              Bool                 | If(App(f, [(x == 1)]), App(g, [x]), 20)
t4              t7                   | If(App(f, [(x == 1)]), App(g, [x]), 20)
t4              Int                  | If(App(f, [(x == 1)]), App(g, [x]), 20)
t0              ((t1, t2, t3) -> t4) | Lambda([f, g, x], If(App(f, [(x == 1)]), App(g, [x]), 20))

Inferred type
----
(((Bool -> Bool), (Int -> Int), Int) -> Int)

There are many more examples of type-inferred microml code snippets in the test file test_typing.py. Here's another example which is interesting:

> foo f x = if x then lambda t -> f(t) else lambda j -> f(x)
((Bool -> a), Bool) -> (Bool -> a)

The actual inference is implemented in typing.py, which is fairly well commented and should be easy to understand after reading this post. The trickiest part is probably the unification algorithm, but that one is just a slight adaptation of the algorithm presented in the previous post.

[1]

After this post was published, it was pointed out that another type checking / inference technique is already called bi-directional (see this paper for example); while it's related to Hindley-Milner (HM), it's a distinct method. Therefore, my terminology here can create a confusion.

I'll emphasize that my only use of the term "bi-directional" is to distinguish what HM does from the simpler "uni-directional" inference described at the beginning.

Go and Algebraic Data Types

2018-09-13T05:40:00-07:00

Algebraic data types (also known as variant types, sum types or discriminated unions) is a neat feature of some programming languages that lets us specify that a value might take one of several related types, and includes convenient syntax for pattern matching on these types at run-time. Here's a canonical binary tree example from Wikipedia, written in Haskell:

data Tree = Empty
          | Leaf Int
          | Node Tree Tree

A Tree can be either empty, or a leaf with one integer field, or a node with two Tree fields - its left and right children. Here's a function that finds the depth of such trees:

depth :: Tree -> Int
depth Empty = 0
depth (Leaf n) = 1
depth (Node l r) = 1 + max (depth l) (depth r)

It takes a Tree and returns an integer, and its workings are laid out by cases, depending on the run-time type of the parameter [1]. If we pass anything that's not a Tree into depth, we'll get an error. Very concise and elegant!

"Why doesn't Go have algebraic data types" is a commonly asked question, and there's a FAQ entry about it. Even more details can be found in a Reddit AMA session the Go developers did in 2016 and in this proposal issue. The short version of the answer is that it isn't clear how this feature would interact with interfaces; how would one variant type discriminate between multiple interfaces that may have the same methods, etc. Indeed, it's a tricky issue and no one has found a satisfactory solution yet.

Another common answer is that Go already supports very similar functionality via a combination of interfaces and run-time type switches. In this post I want to show how it can be done, with some examples from synthetic to "real life". The full code for the samples in this post is available here.

Here's the same binary tree type, written in Go [2]:

type Tree interface {
}

type Empty struct {
}

type Leaf struct {
    v int
}

type Node struct {
    left, right Tree
}

Tree is an interface; Empty, Leaf and Node implement the interface. Note that the Tree interface is empty, so any type implements it, even the built-in string. We can easily restrict this by providing a method that would only be implemented by the interesting types:

type Tree interface {
    isTree()
}

And we'll have to add empty imlementations for our types:

func (_ Leaf) isTree()  {}
func (_ Node) isTree()  {}
func (_ Empty) isTree() {}

Now only types with a isTree method will be allowed where the Tree interface is expected.

The depth function employs a type switch to do run-time type dispatching:

func depth(t Tree) int {
    switch nt := t.(type) {
    case Empty:
        return 0
    case Leaf:
        return 1
    case Node:
        return 1 + max(depth(nt.left), depth(nt.right))
    default:
        log.Fatalf("unexpected type %T", nt)
    }
    return 0
}

It's much more verbose than the Haskell pattern matching, but not less readable, and just as efficient. One obvious deficiency is having to manually reject other types in the default clause; Haskell's pattern matching does this automatically and also makes sure we've covered all cases.

A more realistic example

Let's turn to a more realistic example that you could legitimately encounter in a Go program. Since I'm a compiler nerd this will be about trees again - abstract syntax trees. These data structures are a key layer in most compilers, produced by parsers and consumed by whatever comes after (type checking/inference, lowering, optimization, evaluation, etc).

For this sample I wrote a complete evaluator for a simple calculator language with arithmetic operations, variables you can set and access, and if conditionals. The full code is in parser-evaluator.go; here I'll just focus on the AST nodes and how to "pattern match" them. This is the Node interface:

type Node interface {
    isNode()
    String() string
}

It has the isNode guard method that all concrete node types will implement, along with a String method to make sure all nodes implement the fmt.Stringer interface for debugging. Here are a few sample concrete node types:

type AssignStmt struct {
    Pos  scanner.Position
    Name string
    Expr Node
}

type IfStmt struct {
    Pos  scanner.Position
    Cond Node
    Then Node
    Else Node
}

type IntConstant struct {
    Pos   scanner.Position
    Value int
}

If you look at the full code, all of these have a dummy isNode method, along with a String method.

This is how pattern matching happens in the Eval function that evaluates an expression:

func (eval *Evaluator) Eval(n Node) (int, error) {
    switch nt := n.(type) {
    case IntConstant:
        return nt.Value, nil
    // ...
    // ... more cases
    // ...
    case AssignStmt:
        val, err := eval.Eval(nt.Expr)
        if err != nil {
            return 0, err
        }
        eval.symbolTable[nt.Name] = val
        return 0, nil
    case IfStmt:
        condVal, err := eval.Eval(nt.Cond)
        if err != nil {
            return 0, err
        }
        // Lazily evaluate Then or Else based on the result of Cond.
        if condVal == 0 {
            elseVal, err := eval.Eval(nt.Else)
            if err != nil {
                return 0, err
            }
            return elseVal, nil
        } else {
            thenVal, err := eval.Eval(nt.Then)
            if err != nil {
                return 0, err
            }
            return thenVal, nil
        }
    }
    return 0, fmt.Errorf("unmatched node %s", n)
}

Again, a type switch to cleanly discriminate between all the run-time types n could take.

An even more realistic example

The evaluator shown in the previous section is something you could run into in real programs, and in fact you do. Go's own go/ast package uses the same idiom for its AST nodes [3].

Looking in src/go/ast/ast.go in Go's source code, we see:

// All statement nodes implement the Stmt interface.
type Stmt interface {
    Node
    stmtNode()
}

Node is an embedded interface for some position-related methods, and stmtNode is a dummy method only Stmt types implement. Then, looking in src/go/types/stmt.go we find many examples of the by-now familiar type switch:

// stmt typechecks statement s.
func (check *Checker) stmt(ctxt stmtContext, s ast.Stmt) {
  // ...
    switch s := s.(type) {
    case *ast.BadStmt, *ast.EmptyStmt:
        // ignore
    case *ast.IfStmt:
        check.openScope(s, "if")
        defer check.closeScope()

        check.simpleStmt(s.Init)
        var x operand
        check.expr(&x, s.Cond)
        // ...
    // ...
}

Conclusion

It seems that Go can do just fine without adding variant types, due to the challenges mentioned in the beginning of the post and the ease with which the major use-cases can be implemented using existing language features. While Go's interfaces and type switches are certainly more verbose than Haskell's ADT declarations with pattern matching, and provide a bit less static safety, they are nevertheless fully usable for the task and just as efficient.

Language design is a careful balance, and a lot can be said for keeping the language simple with a minimal number of features, even if this leads to small losses in expressivity. It's not worth adding a significant language feature just to cover for a small weakness in the existing ones that can be easily worked around.

[1]	It's important to note that this is run-time type dispatch; the value has to have a run-time tag saying what its type is. This will be important in comparing with the Go implementation later on.

[2]	This is not the idiomatic way of writing binary trees in Go, it's just here to provide a syntactically close comparison to the Haskell code.

[3]	`go/ast` is a library package useful for constructing tools to process Go code. The Go compiler is now itself written in Go and has similar code in it (though AFAICT it's incompatible with the public-facing `go/ast`).

More thoughts on the Expression Problem in Haskell

2018-02-05T06:45:00-08:00

My previous post discussed the Expression Problem and presented code in several languages to demonstrate the issue and some solutions. Haskell was used as the poster boy for functional languages which suffer from the problem in one of its dimensions (particularly - it being easy to add new functions but not new types).

In comments to that post (and other comments made online) it was pointed out that using typeclasses could help solve or alleviate the problem in Haskell, and I want to fix any misconceptions by pursuing this approach right now. While typeclasses can help work around some issues related to the Expression Problem, they don't provide a complete solution - at least not in the way usually presented in online tutorials. For a more complete solution, we'll going to dig a bit deeper.

A quick recap

The Expression Problem in Haskell can be demonstrated with the following code:

data Expr = Constant Double
          | BinaryPlus Expr Expr

stringify :: Expr -> String
stringify (Constant c) = show c
stringify (BinaryPlus lhs rhs) = stringify lhs
                                ++ " + "
                                ++ stringify rhs

evaluate :: Expr -> Double
evaluate (Constant c) = c
evaluate (BinaryPlus lhs rhs) = evaluate lhs + evaluate rhs

While it's easy to add new functions (for example typecheck) without modifying existing code, the same cannot be said of new expression types. If we add a new type - say BinaryMul, we'll have to modify a whole bunch of existing code - the definitions of stringify and evaluate (and typecheck if we already had it).

Typeclasses to the rescue

The following shows how to "solve" the aforementioned issue with typeclasses. The word "solve" is in quotes for a reason - this is not a complete solution, as we shall soon see. And yet, this is the most common solution you will find online, so I wanted to inspect it in detail before we go deeper.

We start by definiting the data types for different nodes:

data Constant           = Constant Double deriving (Show)
data BinaryPlus lhs rhs = BinaryPlus lhs rhs deriving (Show)

They are separate now, and not variants of the same data. Having all nodes under the same data created the expression problem in the first place, because we had to update the pattern matching rules in every function whenever a new type is added.

We tie them together with an empty typeclass [1]:

class Expr e

instance Expr Constant
instance (Expr lhs, Expr rhs) => Expr (BinaryPlus lhs rhs)

So now, even though Constant and BinaryPlus are completely different data types, they are both instances of Expr, which provides a unification point by letting functions and other classes require an Expr-implementing type in parameters, etc.

Let's implement evaluation for these expressions:

class (Expr e) => Eval e where
  evaluate :: e -> Double

instance Eval Constant where
  evaluate (Constant x) = x

instance (Eval lhs, Eval rhs) => Eval (BinaryPlus lhs rhs) where
  evaluate (BinaryPlus lhsx rhsx) = evaluate lhsx + evaluate rhsx

Now we can do this from a terminal:

> let e = BinaryPlus (Constant 1.1) (Constant 2.2)
> evaluate e
3.3000000000000003

Adding new functions is fairly easy:

class (Expr e) => Stringify e where
  stringify :: e -> String

instance Stringify Constant where
  stringify (Constant x) = show x

instance (Stringify lhs, Stringify rhs) => Stringify (BinaryPlus lhs rhs) where
  stringify (BinaryPlus lhsx rhsx) = printf "(%s + %s)"
                                       (stringify lhsx) (stringify rhsx)

As before, we didn't have to modify any of the existing code to add this, so that's good. What about new types though, will it be easier this time? Let's add a BinaryMul node:

data BinaryMul lhs rhs = BinaryMul lhs rhs deriving (Show)

instance (Expr lhs, Expr rhs) => Expr (BinaryMul lhs rhs)

instance (Eval lhs, Eval rhs) => Eval (BinaryMul lhs rhs) where
  evaluate (BinaryMul lhsx rhsx) = evaluate lhsx * evaluate rhsx

instance (Stringify lhs, Stringify rhs) => Stringify (BinaryMul lhs rhs) where
  stringify (BinaryMul lhsx rhsx) = printf "(%s * %s)"
                                      (stringify lhsx) (stringify rhsx)

Taking it for a ride:

> let d = BinaryMul (Constant 2.0) (BinaryPlus (Constant 2.0) (Constant 0.5))
> evaluate d
5.0
> stringify d
"(2.0 * (2.0 + 0.5))"

It works! And note that we didn't have to modify any existing code to add a new type - instance definitions live outside their original class, so they can be defined for new types without touching existing code (not unlike the Clojure multimethods discussed in the original post).

So this is it! Problem solved, right? Well, no. It does seem like we've managed to add both a new function and a new type without modifying existing code, but if we think about it a bit deeper - there's a huge problem lurking here. Can you figure it out?

Alright, a hint. Imagine you want to write a function that parses a string and produces an expression. What would the type of this function be? Specifically, what is its return type?

When we split up Constant and BinaryPlus to different data types, we gained the ability to sidestep the expression problem, but we lost something valuable too - the ability to unify them under a single type. No, a parsing function cannot return Expr - Expr is not a type, it's a type class. Here's a slightly different demonstration:

> let x = 20
> let k = if x > 4 then (Constant 2.2) else (BinaryPlus (Constant 5.5) (Constant 2.1))

<interactive>:43:44:
    Couldn't match expected type `Constant'
                with actual type `BinaryPlus Constant Constant'
    In the return type of a call of `BinaryPlus'
    In the expression: (BinaryPlus (Constant 5.5) (Constant 2.1))
    In the expression:
      if x > 4 then
          (Constant 2.2)
      else
          (BinaryPlus (Constant 5.5) (Constant 2.1))

Haskell won't have it. The type of k can be inferred to either Constant or BinaryPlus, but this has to be done at compile-time. This expression tries to flip the type based on a run-time value, and that just isn't possible [2].

To make this work, we'll need to rethink our data declarations again, attempting to unify different expression in a way that a single type can be returned from functions. This complicates the code considerably, so take a deep breath before reading on.

Combining type constructors

Disclaimer: the following is my exposition of the first part of Wouter Swierstra's paper "Data types a la carte". I'm also indebted to Bartosz Milewski for discussing the problem mentioned above with me and his kind suggestion to read this paper.

The last section ended with a problem - how to combine the different expression types in a way that we could use a single type to refer to them? One idea that can come to mind is using something like Either. Here's a conditional assignment similar to the one shown before:

> let k = if x > 4 then Left "Foo" else Right 20
> :t k
k :: Either [Char] Integer

However, using Either directly presents some immediate challenges:

Either expects concrete types, not type constructors. Its kind is * -> * -> *. Our expression types, like BinaryPlus, are type constructors (they accept type arguments).
Either supports two types - but we may need many more (a realistic case would have dozens of expression types).

So we're not going to be using Either itself, but rather are going to keep it in mind as inspiration.

In fact, we're going to start with something similar, by defining this type:

data ET f g e = El (f e) | Er (g e)

It's a bit like Either, just for type constructors. It takes three parameters: f and g are type constructors, and e is a type that can be passed to these type constructors. ET "unifies" them in a way similar to Either. In the paper, Swierstra refers to ET as the coproduct of the signatures of f and g.

But how do such type constructors look? Here comes the tricky part, so get some paper and think this through:

data Expr f = In (f (Expr f))

Yes, this is a recursive type declaration. Note that both Expr and f are type constructors here; f takes a type parameter corresponding to the expressions that occur as the subtrees of constructors.

Let's get to the more concrete types. Here are some of the familiar expression node types:

data Constant e = Constant Double
data BinaryPlus e = BinaryPlus e e
data BinaryMul e = BinaryMul e e

Note that:

They are separate types, not under the same data declaration. Recall that this part is important for solving the expression problem. This led to another problem in the previous section, but we'll soon see how the clever Expr shown here will help us overcome it.
They all accept a type parameter e; this is in preparation for making them more generic in the sense of Expr f.

These types can be made instances of Functor so that we can map things over them in a uniform way:

instance Functor Constant where
  fmap f (Constant x) = Constant x

instance Functor BinaryPlus where
  fmap f (BinaryPlus e1 e2) = BinaryPlus (f e1) (f e2)

instance Functor BinaryMul where
  fmap f (BinaryMul e1 e2) = BinaryMul (f e1) (f e2)

Importantly, the coproduct ET is also a Functor:

instance (Functor f, Functor g) => Functor (ET f g) where
  fmap f (El e1) = El (fmap f e1)
  fmap f (Er e2) = Er (fmap f e2)

Another important piece of the puzzle is foldExpr, which lets us perform a fold on an expression:

foldExpr :: Functor f => (f a -> a) -> Expr f -> a
foldExpr f (In t) = f (fmap (foldExpr f) t)

foldExpr takes a function that extracts the value from inside a functor, and an Expr. It uses fmap to recursively extract a value from the contained type. This is getting a bit complicated - an example will soon help clarify things.

Finally, we're ready to define some operations on these expressions. Let's start with evaluate:

class Functor f => Eval f where
  evalFunctor :: f Double -> Double

instance Eval Constant where
  evalFunctor (Constant x) = x

instance Eval BinaryPlus where
  evalFunctor (BinaryPlus x y) = x + y

instance Eval BinaryMul where
  evalFunctor (BinaryMul x y) = x * y

instance (Eval f, Eval g) => Eval (ET f g) where
  evalFunctor (El x) = evalFunctor x
  evalFunctor (Er y) = evalFunctor y

evaluate :: Eval f => Expr f -> Double
evaluate expr = foldExpr evalFunctor expr

First, Eval is a typeclass that supports the evalFunctor function which produces a Double from an expression. Instances for our data types are trivial, and the instance for ET simply propagates left or right based on the combinator's contents.

We're ready for an example. Let's start by defining a type that unifies all our three existing expression types:

type GeneralExpr = Expr (ET Constant (ET BinaryPlus BinaryMul))

This simply builds a binary tree of types; think of Either again - this is like the variable-length version of Either, just for types. Here's how it looks:

        ET
       /  \
      /    \
     /      \
Constant    ET
           /  \
          /    \
         /   BinaryMul
        /
  BinaryPlus

As an example, we can define a simple constant and evaluate it as follows:

> let x = In(El(Constant 7.0)) :: GeneralExpr
> evaluate x
7.0

Do you see why x is defined the way it is? We just follow the tree; one step left (El) and we get to Constant; then wrap it in In to make it an Expr, done. Now, what happens when evaluate x is called? Let's trace it through:

-> evaluate x

... x is of type GeneralExpr, so it's an Expr, and also satisfies Eval because
... there's an instance of Eval for ET

-> foldExpr evalFunctor x
-> evalFunctor (fmap (foldExpr evalFunctor) (El(Constant 7.0)))

... first, this fmap-s something on El(Constant 7.0); looking up the fmap
... definition for ET, this turns into El(fmap <...> (Constant 7.0))

-> evalFunctor El(fmap (foldExpr evalFunctor) (Constant 7.0))

... but fmap-ing anything onto Constant just produces that Constant, so:

-> evalFunctor El(Constant 7.0)

... looking up the instance of Eval for ET, we see that for (El x) we invoke
... evalFunctor x

-> evalFunctor(Constant 7.0)

... and finally, for evalFunctor (Constant x) the answer is x

-> 7.0

Now let's define a more complicated expression:

> let y = In(El(Constant 2.0)) :: GeneralExpr
> let mulXY = In(Er(Er(BinaryMul x y))) :: GeneralExpr
> let addXmulXY = In(Er(El(BinaryPlus x mulXY))) :: GeneralExpr
> evaluate addXmulXY -- note: this does "x + xy"
21.0

It may take longer, but it should be fairly straightforward to trace through this evaluate similarly to the simpler case above. I recommend it as an exercise! Pay special attention to how BinaryPlus and BinaryMul nodes are created by picking the right path through the ET tree defined for GeneralExpr.

It's time to see how to add new functions to this solution. Let's add stringify; it's very straightforward now that we know how evaluate is done:

class Functor f => Stringify f where
  stringifyFunctor :: f String -> String

instance Stringify Constant where
  stringifyFunctor (Constant x) = show x

instance Stringify BinaryPlus where
  stringifyFunctor (BinaryPlus x y) = "(" ++ x ++ " + " ++ y ++ ")"

instance Stringify BinaryMul where
  stringifyFunctor (BinaryMul x y) = "(" ++ x ++ " * " ++ y ++ ")"

instance (Stringify f, Stringify g) => Stringify (ET f g) where
  stringifyFunctor (El x) = stringifyFunctor x
  stringifyFunctor (Er y) = stringifyFunctor y

stringify :: Stringify f => Expr f -> String
stringify expr = foldExpr stringifyFunctor expr

It follows exactly the same pattern, and of course no modification of existing code is required. Since our node types don't reside in a single data type, there's no pattern matching to update. The new functionality is provided by instances of the Stringify typeclass.

> stringify x
"7.0"
> stringify addXmulXY
"(7.0 + (7.0 * 2.0))"

Reflecting on the combinator technique

The technique presented in the previous section solves the expression problem. It also doesn't suffer from the problem with the simpler typeclass approach, because we now actually have Expr as a unifying type. To go back to the previous attempt to conditionally define a value of either type:

> let k = if p > 4 then x else addXYmulX
> :t k
k :: GeneralExpr
> evaluate k
7.0

w00t, it works! So now we can actually write a parser that will return GeneralExpr, with the actual node type determined at run-time.

Not everything is perfect, though. There are a couple of problems with this approach. First, it's really tedious to create expressions. Recall the sequence of temporary lets required to create the addXmulXY node, and these nestings of El and Er are quite tiresome.

Also, if we add more node types to our expression language, these definitions will get even more complicated because the ET tree will get deeper; and finally, the worst problem of all, we'd have to rewrite the existing code that creates expressions because the El / Er paths change. Note that we won't have to modify the definitions of existing nodes; nor will we have to modify the definitions of the existing functions like evaluate and stringify (only add instances for new types), so the expression problem isn't violated, strictly speaking.

There are a number of solutions possible for these problems, all of which make the code even more complicated (FWIW I find the existing approach of the recursive Expr definition pretty obtuse already). If you keep reading Swierstra's paper, section 4 discusses one mitigation by creating smarter constructors; it even goes as far as to veer off the Haskell 98 standard, requiring language extension support.

To be honest, I think this exploration went too far into the land of code complexity already. How bad is the expression problem really? Why is it such a taboo to modify existing code? Healthy code bases should be continously tended to and refactored, in my view, and there's nothing wrong with modifying existing code to generalize it. Sure, when the solution is as trivial as in Clojure, the cost of maintaining these invariants is fairly small. But the approach presented here for Haskell is so complex that I'd be careful about using it in real life. There's a cost-benefit analysis to be made here, and I'm not sure which way it would go.

[1]	This typeclass is empty in the sense that it doesn't declare any methods that need to be implemented by instances. Therefore any type can be made an instance of this class just by declaring it as such.

[2]	Incidentally, Clojure's dynamic nature is precisely what makes this a non-problem in the Clojure multiple dispatch solution. Unlike Haskell, Clojure doesn't attempt to infer a compile-time type for every expression and values can hold different types at different times during execution.

[3]	By type constructor I mean a non-nullary type constructor.

Return type polymorphism in Haskell

2018-01-30T05:15:00-08:00

In this brief post I want to discuss a fairly unusual feature of Haskell - functions that can be parameterized by their return type.

Parametric vs. ad-hoc polymophism

It's worth beginning with a quick discussion of the two most common kinds of compile-time polymorphism present in Haskell: parametric polymophism and ad-hoc polymorphism.

Parametric polymorphism is possible when we can define a certain operation to work similarly on any type. A simple example is the list type [a], on which many operations are defined in a way that completely disregards what the actual type a is. For instance, the function length can find the length of the list without relying or caring about a. A slightly more interesting example is map, defined as follows for lists:

map :: (a -> b) -> [a] -> [b]
map _ []     = []
map f (x:xs) = f x : map f xs

This will work on any list, regardless of what it contains - integers, other lists or some complicated user-defined type. The definition is written in a way that is oblivious to the actual type of a. This kind approach is commonly called generic programming; in C++, it's represented with templates.

This approach is sometimes limiting, however, because we may actually want functions to do something slightly different for every type (or at least for some types). This brings us to ad-hoc polymoprhism, which is represented by either function overloading or template specialization in C++.

Ad-hoc polymorphism in Haskell is achieved by using typeclasses. As an example, consider the built-in class Ord. If you define the <= operator for your type, it's then considered to comply with the Ord class and we can do some interesting things with it [1]. For example, we can implement merge-sorting as follows:

merge :: Ord a => [a] -> [a] -> [a]
merge [] ys = ys
merge xs [] = xs
merge (x:xs) (y:ys)
  | x <= y = x : merge xs (y : ys)
  | otherwise = y : merge (x : xs) ys

msort :: Ord a => [a] -> [a]
msort [x] = [x]
msort xs = merge (msort left) (msort right)
  where
    (left, right) = (take halflen xs, drop halflen xs)
    halflen = length xs `div` 2

Note that msort works on a list of some type a, similarly to map; in this respect it's parametrically polymorphic, with a twist. The type constraint Ord a => tells the compiler that it's only legal to invoke msort on lists of type a if a implements the Ord class.

Most built-in Haskell types implement the Ord ord class, so we can use msort right away:

> msort [2,1,3,8,5]
[1,2,3,5,8]

However, if we want to use it on user-defined types, we'll need to implement the Ord class manually:

data Person = Person
  { lastName :: String
  , firstName :: String
  } deriving (Eq, Show)

-- Simple example of making Person sortable by defining Ord.
instance Ord Person where
  (Person lx fx) <= (Person ly fy) =
    if lx == ly
      then fx <= fy
      else lx <= ly

Note that this definition of <= relies on some semantic properties of the custom type (that last name is usually sorted before first name) that Haskell has no way of knowing. This is why ad-hoc is often necessary - per-type definitions describe a real-life domain in some way; for example, had Person had some unique ID it would be perhaps more correct to sort people by this ID.

Having done this, we can now sort a list of Persons:

> let folks = [(Person "Jones" "Jan"), (Person "Jones" "Areo"),
               (Person "Falcon" "Hugo"), (Person "Spearson" "Britney")]
> msort folks
[Person {lastName = "Falcon", firstName = "Hugo"},
 Person {lastName = "Jones", firstName = "Areo"},
 Person {lastName = "Jones", firstName = "Jan"},
 Person {lastName = "Spearson", firstName = "Britney"}]

It's important to reiterate that this example showcases both kinds of polymoprhism. msort is parametrically polymoprhic - it's the same code that will work for any type a, as long as a implements Ord. On the other hand, the <= operator is ad-hoc polymorphic - it works on different types, but each type should define its own version.

Return-type polymophism

Now that we have the above covered, it's time to turn to the main topic of this post - return-type polymophism. Combined with type inference, this is a fairly unique and cool aspect of Haskell, especially if you come from the C++ world where templates provide some degree of parametricity but it's limited in certain other ways.

Let's start with an example, the built-in function read:

read :: Read a => String -> a

The read function reads input from a string, which must be completely consumed
by the input process.

Something interesting is happening here: read is parameterized by type a, but this type is not one of its arguments; no, the argument of read is simply a String, which is a concrete type. a appears only in the return type.

Let's try to parse an integer by using read:

> read "1"

<interactive>:46:1:
    No instance for (Read a0) arising from a use of `read'
    The type variable `a0' is ambiguous
    Possible fix: add a type signature that fixes these type variable(s)
    <...>

Oops, what went wrong? The issue here is that 1 could be of several types, and Haskell doesn't know which one to choose. We can fix that with an explicit type annotation:

> read "1" :: Int
1

But 1 can also be of other types:

> read "1" :: Double
1.0

So read can truly return multiple types [2], depending on how it's being called. This is return-type polymorphism.

Here's a more intriguing example:

> putStrLn (take (read "2") (read "\"haskell\""))
ha

Haskell didn't complain about read "2", even though no type annotation was provided. What's going on? The answer is type inference. Haskell looks at that code and sees the result of read "2" being fed into take, as its first argument. The type of take is Int -> [a] -> [a], so the result of read "2" is placed in an Int. This interaction of type inference with return-type polymophism is one of the most impressive features of Haskell, IMHO!

Now let's turn to a slightly more interesting example - monoids. I've mentioned the Monoid type class before, in the context of folds.

class Monoid a where

  The class of monoids (types with an associative binary operation that has an
  identity).

To create a new Monoid, we have to define two functions:

mempty :: a

  Identity of mappend

mappend :: a -> a -> a

  An associative operation

Note the type of mempty - it takes no arguments, but returns an arbitrary type a - return-type polymorphism. Here's how Haskell defines Monoid for lists:

instance Monoid [a] where
        mempty  = []
        mappend = (++)
        mconcat xss = [x | xs <- xss, x <- xs]

With this definition, we could use mempty for strings as follows:

> mempty :: String
""

For numbers, things are somewhat more interesting because there are two ways to define monoids on integers. One is using addition as the associative operation, another is using multiplication. In the former case, the zero element is 0, in the latter it's 1. Since there is no scenario which is clearly better than the other, Haskell doesn't define Monoid for Int:

> mempty :: Int

<interactive>:11:1:
    No instance for (Monoid Int) arising from a use of `mempty'
    Possible fix: add an instance declaration for (Monoid Int)

Rather, it adds two new types that wrap Int: Sum and Product. Here's an example:

> mempty :: Sum Int
Sum {getSum = 0}
> mappend (Sum 6) (Sum 7)
Sum {getSum = 13}

As before with read, note how mempty returns a different type based on what's expected from it. Type inference picks the right overload! In the following sample, type inference knows that mappend takes two arguments of the same type and the first one is a String, so it invokes the String-returning version of mempty:

> mappend "Foobar" mempty
"Foobar"

Similarly, here the Sum-returning version is invoked due to type inference:

> mappend (Sum 10) mempty
Sum {getSum = 10}

Providing multiple capabilities from the same function

I'll conclude with another cool example of return-type polymoprhism from the Haskell standard library: regular expression matching [3]. Haskell defines the RegexLike typeclass as an interface for regex-like matchers. It has the usual zoo of methods one can define (and if undefined, will use one another as the default implementation), with another class for the more generic usage:

-- | RegexContext is the polymorphic interface to do matching.  Since
-- 'target' is polymorphic you may need to suply the type explicitly
-- in contexts where it cannot be inferred.
-- <...>
class (RegexLike regex source) => RegexContext regex source target where
  match :: regex -> source -> target
  matchM :: (Monad m) => regex -> source -> m target

Feel free to dig in the source to see how it's all hooked up (a good example of building high-level abstractions with Haskell!), but match is wrapped in the =~ operator, which behaves polymophically based on the expected return type. In Bool context, is finds whether the match exists at all (this corresponds to the matchTest method of RegexLike):

> "january" =~ "an(ua)*" :: Bool
True

While in Int context, it counts the number of matches (this corresponds to matchCount):

> "january" =~ "an(ua)*" :: Int
1
> "january" =~ "a" :: Int
2

And so on... there are a few more possibilities (like returning the actual list of matches). Depending on your point of view, this is either extremely cool or scary, because sometimes the programmer has to perform type inference in their head to follow the path the compiler is taken, which can make code tricky to understand.

[1] This explanation over-simplifies a bit. The definition of Ord showcases other features of Haskell. First, Ord can only be defined on classes for which Eq is defined - this is enforced by the compiler. Second, Ord has default implementations for a bunch of functions so it suffices to define either <= or compare and get a bunch of others automatically provided.

[2]	With different implementations for different types, of course. Parsing a `Double` from a string is different from parsing an `Int`.

[3]	Inspired by this article by Matthew Manela - thanks, Matthew!

Haskell functions as functors, applicatives and monads

2018-01-22T05:19:00-08:00

This post explores how functions in Haskell can be seen as instances of the Functor, Applicative and Monad type classes, with some reflection on the practical uses of this technique.

Function as an instance of Functor

class Functor f where
  fmap :: (a -> b) -> f a -> f b

Types parameterized by a single type can be instances of Functor if they implement fmap in a way that follows the functor laws. The simplest example is Maybe; Maybe is a type parameterized by a single type (also known as type constructor):

data Maybe a = Nothing | Just a

Maybe is a Functor:

instance Functor Maybe where
  -- fmap :: (a -> b) -> Maybe a -> Maybe b
  fmap _ Nothing = Nothing
  fmap g (Just x) = Just (g x)

So what about functions? In general, a function (->) is parameterized by two types: a -> b or alternatively (->) a b - both a (the function argument) and b (the function return value) can have arbitrary types for an arbitrary function. So functions aren't a good fit for Functor, unless we tweak something.

The tweak is to fix the argument type, leaving only the return type arbitrary. This is written as (->) a, a type parameterized by a single type - the return value (the argument type is fixed at a). Haskell type constructors can be partially applied, same as functions. As an example, consider Either, which is a type constructor parameterized by two types [1]:

> :kind Either
Either :: * -> * -> *

If we partially apply the Either type constructor we get another type constructor, this time with a single type parameter:

> :kind Either Int
Either Int :: * -> *

Similarly, we can check the kind of functions:

> :kind (->)
(->) :: * -> * -> *

And of partially-applied functions:

> :kind ((->) Int)
((->) Int) :: * -> *

Before showing how (->) a is an instance of Functor, let's reformulate it in a slightly more explicit way. Let's use FuncWithArgA to name the concept of "a function with argument of type a". This type is parameterized by a single type: b, the return value type.

So if we had to make FuncWithArgA an instance of Functor, the type of fmap would be:

fmap :: (b -> c) -> FuncWithArgA b -> FuncWithArgA c

That is, we map a function b -> c onto FuncWithArgA b to produce FuncWithArgA c. Now if we go back to the actual type of functions parameterized by the return type, we get:

fmap :: (b -> c) -> ((->) a) b -> ((->) a) c

... or

fmap :: (b -> c) -> (a -> b) -> (a -> c)

So this should be the type of fmap for functions. One way to make this work would be [2]:

instance Functor ((->) a) where
  fmap g ff = \x -> g (ff x)

Let's follow the types: ff is our functor - it's a function a -> b. The mapped function g is b -> c. Hence, the result of fmap is a function taking a and returning c, or a -> c, so this matches the expected type.

Note that \x -> g (ff x) is precisely the composition of g onto ff, or g . ff in Haskell notation. So being extra clever, we can use point-free notation to rewrite our Functor instance as:

instance Functor ((->) a) where
  fmap = (.)

Now it's time for an example. Let's take the function replicate:

replicate :: Int -> a -> [a]

By itself, replicate has two arguments, so it's not a good match for our Functor. But if we partially apply it, it will be. Say replicate 4. Its type is:

> :t replicate 4
replicate 4 :: b -> [b]

replicate 4 is a function a single parameter - a perfect fit for Functor. So we can use fmap on it! Let's fmap the function show on it. show takes any "showable" type and produces String. Therefore:

> :t fmap show (replicate 4)
fmap show (replicate 4) :: Show a => a -> String

Let's check the type of fmap:

replicate 4 is b -> [b]
show is Show a => a -> String; in this case [b] -> String
So fmap show (replicate 4) is b -> String, via function composition

We can try it on different types:

> fmap show (replicate 4) 5
"[5,5,5,5]"
> fmap show (replicate 4) (Just 6)
"[Just 6,Just 6,Just 6,Just 6]"

Functor laws for functions

To be a proper Functor in Haskell, it isn't sufficient to define a Functor instance that type-checks. In addition, the definition has to satisfy the functor laws:

fmap id = id
fmap (g . h) = fmap g . fmap h

Explaining how the Functor instance for functions shown above satisfies these laws is a great exercise in mind-bending Haskell notation, and really stresses our grasp of types and type constructors. Let's get to it.

Two factors that make such derivations difficult to follow for beginners in Haskell are point-free style and currying. As an example, what does fmap id mean [3]?

We know that fmap takes two arguments: a mapped function and the functor. fmap id is partially applied, or curried - it's another function that already accounts for the mapped function so it only takes a single argument - the functor. All Haskell functions are curried by default, so any multi-argument function can be expressed as a single-argument function returning a function. In the case of fmap:

fmap g ff = \x -> g (ff x)

... can be written as

fmap g = \ff -> \x -> g (ff x)

This helps, because now we can write down what fmap id is:

fmap id = \ff -> \x -> id (ff x)

... or

fmap id = \ff -> \x -> ff x

And this is exactly id, because it takes ff and returns a function that takes an argument and applies ff to it - which is just ff itself. So the first functor law holds. Let's take a look at the second one:

fmap (g . h) = fmap g . fmap h

As before, fmap (g . h) can be written more explicitly as:

fmap (g . h) ff = \x -> (g . h) (ff x)
                = \x -> g (h (ff x))

On the other hand:

(fmap g . fmap h) ff
  = fmap g (fmap h ff)

  ... by definition of "fmap h ff"

  = fmap g (\x -> h (ff x))

  ... by definition of "fmap g ff" for ff now being (fmap h ff)

  = \y -> g ((\x -> h (ff x)) y)
  = \y -> g (h (ff y))

So the second law holds as well, meaning that our Functor instance for functions is legitimate.

Function as an instance of Applicative

Let's now move on to how functions are defined to be instances of Applicative. A reminder:

class Functor f => Applicative f where
  pure :: a -> f a
  (<*>) :: f (a -> b) -> f a -> f b

Let's start by figuring out the types of these methods in a function instance, using the helper FuncWithArgA substitute.

pure :: b -> FuncWithArgA b

Replacing FuncWithArgA by (->) a, we get:

pure :: b -> (a -> b)

A function that satisfies this type is:

pure = \x -> (\y -> x)

This is a very peculiar function, you'll notice. It takes two arguments and returns the first, completely ignoring the second. Haskell already has such a function in the standard library, it's called const:

> :t const
const :: a -> b -> a
> :t const 10
const 10 :: Num a => b -> a
> (const 10) "foo"
10
> (const 10) (Just 20)
10

Using point-free style, pure is defined as:

pure = const

Now let's turn our attention to the <*> operator. Once again, we'll be using FuncWithArgA; to make it more readable I'll rename the types in the declaration of <*>, since a is already implied in FuncWithArgA:

(<*>) :: FuncWithArgA (b -> c) -> FuncWithArgA b -> FuncWithArgA c

.. replacing FuncWithArgA by ((->) a)

(<*>) :: (a -> (b -> c)) -> (a -> b) -> (a -> c)

A definition that satisfies this type is:

g <*> h = \x -> g x (h x)

The type of g is a -> b -> c and the type of h is a -> b; hence, for a parameter of type a, the type of the expression is indeed a -> c.

To conclude, the Applicative instance for functions looks like this:

instance Applicative ((->) a) where
  pure = const
  g <*> h = \x -> g x (h x)

Applicative laws for functions

Let's see how the instance defined satisfies the applicative laws:

pure id <*> x = x
pure (g x) = pure g <*> pure x
x <*> pure y = pure (\g -> g y) <*> x
x <*> (y <*> z) = (pure (.) <*> x <*> y) <*> z

Starting with the first law [4]:

pure id <*> x

.. by definition of pure

(\x -> (\y -> x)) id <*> x
(\y -> id) <*> x

.. by definition of <*>, with (\y -> id) for g and x for h

\z -> (\y -> id) z (x z)

.. using partial function application

\z -> id (x z)
\z -> x z

Which is just another way of saying x - a function taking a single parameter and applying x to it. The first law holds! For the second law:

pure (g x)

.. by definition of pure

\y -> g x

Right-hand side:

pure g <*> pure x

.. by definition of pure

\y -> g <*> \z -> x

.. by definition of <*>

\t -> (\y -> g) t ((\z -> x) t)
\t -> (\y -> g) t x
\t -> g x

The third law, left-hand side:

x <*> pure y
x <*> \z -> y

.. by definition of <*>

\t -> x t ((\z -> y) t)
\t -> x t y

Right-hand side:

pure (\g -> g y) <*> x
\z -> (\g -> g y) <*> x

.. by definition of <*>

\t -> (\z -> (\g -> g y)) t (x t)
\t -> (\g -> g y) (x t)
\t -> x t y

The fourth law, left-hand side:

x <*> (y <*> z)
x <*> (\t -> y t (z t))
\g -> x g ((\t-> y t (z t)) g)
\g -> x g (y g (z g))

Right-hand side:

(pure (.) <*> x <*> y) <*> z
((\t -> (.) (x t)) <*> y) <*> z
(\g -> ((.) (x g)) (y g)) <*> z
\v -> x v ((y v) (z v))

Function as an instance of Monad

Finally, let's see how functions are instances of Monad, which is defined as:

class Applicative m => Monad m where
  return :: a -> m a
  (>>=) :: m a -> (a -> m b) -> m b

For functions, starting with the FuncWithArgA helper:

return :: b -> FuncWithArgA b

Which, as for Applicative has the type:

b -> a -> b

Which is satisfied by the same function, const:

return = const

Now, on to >>=:

>>= :: FuncWithArgA b -> (b -> FuncWithArgA c) -> FuncWithArgA c

.. Unpacking the ``FuncWithArgA`` helper:

>>= :: (a -> b) -> (b -> (a -> c)) -> (a -> c)
>>= :: (a -> b) -> (b -> a -> c) -> (a -> c)

A definition that satisfies this type is:

g >>= h = \x -> h (g x) x

Monad laws for functions

The monad laws are:

return x >>= f = f x
mx >>= return = mx
(mx >>= f) >>= g = mx >>= (\x -> (f x >>= g))

Let's start with the first law. Left-hand side:

return x = \y -> x
return x >>= f = \t -> f ((\y -> x) t) t
               = \t -> f x t

This is equivalent to f x, which is in point-free style. The left-hand side for the second law:

mx >>= return = \t -> return (mx t) t

              .. by definition of return, returns the first argument whenever
                 applied.

              = \t -> mx t

This can be written as just mx in point-free style. Finally, the third law. Left-hand side:

(mx >> f) >>= g = (\x -> f (mx x) x) >>= g
                = \t -> g ((\x -> f (mx x) x) t) t
                = \t -> g (f (mx t) t) t

Right-hand side:

mx >>= (\x -> (f x >>= g)) = mx >>= (\x -> (\t -> g (f x t) t))
                           = \z -> (\x -> (\t -> g (f x t) t)) (mx z) z
                           = \z -> (\t -> g (f (mx z) t) t) z
                           = \z -> g (f (mx z) z) z

Which is equivalent, modulo the renamed bound variable.

Real-life applicability

Now that we've persevered through the derivations, what practical uses does this technique have? I was wondering the same, so I created a Stack Overflow question that got a couple of answers. The main idea is that it lets us compose functions more succinctly, using more Haskell-y point-free style instead of explicitly creating functions with named parameters.

Consider the following example, taken from the top answer in the linked question. Here's a way to find whether a sequence is ascending:

> and $ (\x -> (zipWith (<=) x (drop 1 x))) [1,2,6,4]
False
> and $ (\x -> (zipWith (<=) x (drop 1 x))) [1,2,6,9]
True

Note that we create an explicit lambda for combining zipWith with its parameters in the right way. Using applicative style, we don't need it and can write the code more succinctly [5]:

> and $ (zipWith (<=) <*> drop 1) [1,2,6,4]
False
> and $ (zipWith (<=) <*> drop 1) [1,2,6,9]
True

Note how this achieves the same, but without the explicit lambda. <*> does the functional composition for us. As an exercise, follow the types of the sub-expressions in the <*> to see how this works.

Is this something you'd use in real programs? Maybe, maybe not. I think it depends on personal and project style. The first (non-applicative) option certainly looks more readable to me, but that's because I'm far from being a Haskell pro. Seasoned Haskellers may find the latter more stylistically appealing because it's more point-free, without naming parameters explicitly.

[1]	These samples show Haskell kinds using the `:kind` query in `ghci`. In `:kind` output, `` denotes concrete values (also known as nullary type contructors), ` -> ` denotes a single-parameter type constructor (for example the kind of `Maybe` is ` -> *`), and so on.

[2]	In fact, it's not just one way to make this work; it's the only way to make this work. `Functor` instances for any given type are unique in Haskell, as long as the functor laws are satisfied. This can be proved but is outside the scope of this article.

[3] Note that in the equation fmap id = id, the types of id are different on the left and on the right. On the left, fmap id takes a functor and returns a functor, while id takes and returns the type parameter of the functor. In other words, for Functor a, id on the left has type a -> a while id on the right has type Functor a -> Functor a.

[4] In this derivation, and throughout the post I'm making liberal use of the power of renaming bound variables in functions. For example I may have a function \x -> foo x on one line, and refer to it as \y -> foo y on another line - the two are equivalent, and this renaming helps avoid name collisions. This is called alpha conversion in Lambda calculus.

[5]	You'll need to import `Control.Applicative` to get access to the built-in applicative instance for functions.