Do notation

Recall that when we write I/O programs we use do notation to sequence the side-effecting operations:

In fact do notation is merely syntactic sugar, which expands to applications of the following bind function, which executes an action then feeds the output to the next action:

The above greet function could also be written with bind explicitly:

Clearly, the do notation is much easier to read, and it is much clearer what is going on! Conveniently, therefore, do notation can be rebound to work with types other than IO - any type T for which there can be bind and return operations, with the following types:

For example, we can write a bind operation for Maybe as follows:

For the return operation, we can use Just. We can use these inside a do block by a do using declaration, which takes the bind and return operations as parameters. For example, a function which adds two Maybe Ints:

This function will extract the values from x and y, if they are available, or return Nothing if they are not. Managing the Nothing cases is achieved by maybeBind, hidden by the do notation.

Haskell programmers will probably have wanted this section to include the word 'monad', so there it was. Any others may feel free not to worry :-).

Idioms

While do notation gives an alternative meaning to sequencing, idioms give an alternative meaning to application. The notation and larger example in this section is inspired by Conor McBride and Ross Paterson's paper "Applicative Programming with Effects".

First, let us revisit m_add above. All it's really doing is applying an operator to two values extracted from Maybe Ints. We could abstract out the application:

Using this, we can write an alternative m_add which uses this alternative notion of function application, with explicit calls to m_app:

Rather than having to insert m_app everywhere there is an application, we can use idiom brackets to do the job for us. The idiom keyword takes two parameters, the first explaining what to do with pure values, the second being the application function.

Any type T can be used in this way, given pure and apply functions with types of the following form:

An error-handling interpreter

Idiom notation is commonly useful when defining evaluators. McBride and Paterson describe such an evaluator, for a language similar to the following:

Expressions in this language are evaluated with respect to an environment, mapping Strings to Int values. We can use a list of pairs for this, and write a fetch function to retrieve the value. This may fail, so it returns a Maybe Int:

It is convenient to define a type synonym for environments. Type synonyms are just functions:

Now we'd like to evaluate things which might fail, which carry an environment, without the noise usually associated with this. Enter the idiom brackets... We'll take our idiom to be Env -> Maybe a.

First, we need to know how to inject pure values into this idiom:

Then we need to know how to apply things which carry an environment and might fail:

Finally, we write the evaluator which can use idiom brackets to evaluate things clearly in this idiom:

We'll set up a simple environment to test the evaluator, and try a couple of expressions. testExpr1 will succeed, but testExpr2 will fail due to using an undefined variable:

And without the idiom brackets...?

To properly appreciate the value of idiom brackets, it's worth seeing what the definition would have looked like without them. The most obvious way uses with to extract the values from the intermediate evaluations:

The situation improves slightly with do notation: