My most recent non-trivial attempt at threads was way back when in college. The course was "TCP/IP Programming." It was the kind of course that didn't interest me just from its title and description. Really, I signed up for it because the best professor in the entire school was delivering it, Dan Duchamp, and this was my last semester. In the end, it actually wound up being an informative course, because networking is not my strong point.

We were warned that the assignments would be in C and would be back-breakers. This almost turned out to be true. I had Duchamp in three other courses, and sometimes he would overstate the scope of a project.

Our projects were:

• a DNS resolver that sent UDP to DNS and relayed the result via TCP back to whomever requested it
• a simulation of ICMP and IP; this is one of the courses that I look back on and think "I can't believe I pulled that off"
• a link-state and distance vector routing simulation
• a simulation of TCP
• port the first assignment to the TCP simulation

Somehow, someway, I had no problem with the first three. Then I read the description of the TCP simulation, and I shuddered when I saw that three threads were required.

I pretty much knew right then that it was over.

In fact, after getting extra help from Duchamp, it became apparent that I needed to use pthread_cond_wait, pthread_cond_timedwait, pthread_mutex_t, and pthread_cond_signal to name a few. These were system calls and types that I had never used before.

Duchamp, bless his heart, claimed that he covered them in the OS course, which I also took with him. While he covered mutexes and locking, we did not make use of condition variables in assignments. So on top of the intellectual burden of dealing with my half-finished attempt at multi-threading, which was already based on a bad thread design (and it was too late to start over), I had to learn and use new system calls correctly.

My point is my last semester of senior year could've been much less stressful if programming with threads wasn't a death trap. At work, I asked our technical lead if they made use of multi-threading in the code, and the answer was a resounding "No, it becomes too ugly too quickly."

What's odd is that in most CRUD apps, concurrency is transparent and under the hood. Most RDBM systems give you this for free in the form of transactional processing.

So something can't be right. It can't be such a nightmare to do something like three threads, one for each layer boundary, plus another to do the real work, but so effortlessly achieve concurrent data access and processing. Why do I have to suffer through concurrency if it is not DB-related?

Then, once upon a time, I was listening to Dot Net Rocks show #269. The guest was Larry O'Brien, who was arguing that the thread-and-lock model is garbage:

Larry O'Brien: Oh, absolutely, but even if you get it and even if you think it's fun, there's a thing about that thread and process model that we have in the CLR today, which I would argue makes it fundamentally broken for business programming. So, check out this scenario. You have a library and it has some publicly available method by which it acquires a lock, right?

Carl Franklin: Yeah.

Larry O'Brien: And holds that lock and returns to you and you go about and do your other thing. If you have another method that calls that library on which that library performs a callback and by a callback I mean all sorts of important things. I'm talking about virtual method calls in a world of object orientation. I'm talking about delegates and events central to graphics programming and I'm talking about lambda expressions, which are coming out in C# 3.0 and they're very important for LINQ. You can never safely have a library that simultaneously has a publicly triggerable lock that executes a callback to client code because it's perfectly legal for the client code to start up a new thread...

Carl Franklin: Yeah.

Larry O'Brien: And within that new thread, call that method attempts to get the lock which is already held by the previous thread and the end result of that is deadlock.

I'd take this even a step further: the thread-and-lock model of concurrency is broken because it is too low-level. Why, in this age of garbage collection, managed code, and workflow engines, hasn't the abstraction level been raised on concurrency as well?

The itching issue that needs scratching is that it has been for quite some time, but only in the niche of databases. Memory management used to be a pest; now there is platform support for garbage collection. We need similar support for concurrency. It was just then that the guys on the show discuss Software Transactional Memory:

Larry O'Brien: Okay. Software Transactional Memory is essentially optimistic locking for memory.

Carl Franklin: Yeah.

Larry O'Brien: You wrap a call or a block in what's essentially a transaction. You say "Atomic, start block" and then you finish the block and it runs at full speed and then you have a follow-along processor that goes through it and it looks for that one in a thousand, one in a million memory collision. If a memory collision has occurred, it retries it.

Carl Franklin: Yeah.

Larry O'Brien: Yeah. It's not at all a bad model.

This would be a giant step forward. It does have its problems, namely that it still requires the programmer to be aware and predict what blocks of code are critical sections in order to mark them off as transactions.

To take it a step higher, using Futures, this sort of demarcation can be delegated to the compiler and/or runtime environment entirely:

Larry O'Brien: Instead of trying to second guess the creation of thread, what you do is you say, "Well, I want this value" you know this value being returned from a function, "but I can either have the value or I can have" what Sutter calls "a Future."

A Future is basically an IOU. Okay, so you have this reference to a Future and when you need it, when you say, "Okay, I want to cash in this IOU" at that point, the system will block and guarantee that the value becomes concrete. So, just by sort of flipping things around from "Okay, let's create processes and kind of second guess how many cores I have" and those sorts of approaches.

This approach says, okay by simply having a whole bunch of IOUs floating around then it becomes possible for the compiler on the runtime to do a lot of really clever reasoning about "Oh hey, look. Here's this IOU, but I know that this IOU won't be required for several hundred milliseconds and so, therefore, I have enough information to distribute that to another core."

The only drawback here is again another programmer-dependent pitfall. Functions that return Futures work best, if at all, when they are pure functions with no side effects. This is a throwback to functional programming, and my personal least-favorite Scheme.

I still favor these methods to the rather Draconian no-shared-mutable-state edict of Erlang:

Carl Franklin: There's no shared memory, right?

Larry O'Brien: Oh, that's huge.

Carl Franklin: Between processes?

Larry O'Brien: That's a huge thing. Really to make Concurrency work at the language level, the number one thing that you want to get rid of is shared mutable state.

Carl Franklin: Yup.

Larry O'Brien: Erlang is single assignment to variables...

This is why I think Polyphonic C# is a nice try but gives me some of the same headaches I felt at the start of this post.

It is ultimately a trade-off between shared mutable state (and thus performance) a la Futures and functional programming, and clarity (and thus less performance) a la STM. I think this trade-off is a familiar one to most people in this field. Moreover, I'll say that this trade-off is as innate to our field as Brooks' Law.

I maintain that abstractions like STM and Futures are going to be very important for us software developers in the coming decade if we are to make affordable full use of the next wave of hardware.

Basically... if symbolic systems terminate (program halts/gives output), the terminating expression is independent of how the rules were applied.

You get "confluence" out of this.

You probably are thinking, "and so what does this have to do with my life?"

a) maybe nothing if arithmetic never enters your life (unlikely)

b) it's extremely good to know when you use functional programming that you can get to the same answer with many different ways of writing something.  For good overview of functional programming, go here.

Damon pointed out that the Parallel Extensions library contains a Future<T> class, so I started looking around for examples and explanations of how they work, what the syntax is like, and I ran across a frightening example implementing the asynchronous programming model with Future<T>, as well as going in the other direction, wrapping an APM implementation with Future<T>.  Other articles give pretty good explanations but trivial examples.  From what I gathered briefly, the ContinueWith method for specifying the next step of calculation to process doesn’t seem to provide an intuitive way to indicate that several calculations may be depending upon the current one (unless it can be called multiple times?).  Using ContinueWith, you’re always specifying forward the calculation task that depends on the current future object.  It also surprised me a little that Future inherits from Task, because my understanding of a future is that it’s primarily defined as a value-holding object.  But considering that a future really holds an expression that needs to be calculated, making Future a Task doesn’t seem so odd.

So I decided to implement my own Future<T> class before looking at the parallel extensions library too deeply.  I didn’t want to prejudice my solution, because I wanted to make an exercise of it and see what I would naturally come up with.

Though I tried avoiding prejudice, I still wound up characterizing it in my head as an task, and thought that a future would simply be a pair of Action and Reaction methods (both of the Action delegate type).  The Action would execute and could do whatever it liked, including evaluate some expression and store it in a variable.  If the Action completed, the Reaction method (a continuation) would run, and these could be specified using lambdas.  Because I was storing the results in a local variable (result), swallowed up and made accessible with a closure, I didn’t see a need for a Value property in the future and therefore no need to make the type generic.  Ultimately I thought it silly to have a Reaction method, since anything you needed to happen sequentially after a successful Action, you could simply store at the end of the Action method itself.

FutureTask task = new FutureTask(
    () => result = CalculatePi(10),
    () => new FutureTask(
        () => result += "...",
        () => Console.WriteLine(result),
        ex2 => Console.WriteLine("ex2: " + ex2.Message)),
    ex1 => Console.WriteLine("ex1: " + ex1.Message));

The syntax is what I was most concerned with, and as I started playing around with nesting of futures to compose my calculation, I started to feel like I was onto something.  After all, it was almost starting to resemble some of the F# code I’ve been looking at, and I took that style of functional composition to be a good sign.  As you can see from the code above, I also include a constructor parameter of type Action<Exception> for compensation logic to run in the event that the original action fails.  (The result variable is a string, CalculatePi returns a string, and so the concatenation of the ellipsis really does make sense here.)

The problem that started nagging me was the thought that a composite computation of future objects might not be able to be defined all in one statement like this, not building the dependency tree from the bottom up.  You can really only define the most basic factors (the leaf nodes of a dependency tree) at the beginning this way, and then the expressions that depend directly upon those leaf nodes, etc.  What if you have 50 different starting future values, and you can only proceed with the next step in the calculation once 5 of those specific futures have completed evaluation?  How would you express those dependencies with this approach?

That’s when I started to think about futures as top-down hierarchical data container objects, instead of tasks that have pointers to some next task in a sequence.  I created a Future<T> class whose constructor takes an optional name (to aid debugging), a method of type Func<T> (which is a simple expression, supplied as a lambda in my examples), and finally an optional params list of other Future<T> objects on which that future value depends.

The first two futures in the code below start calculating pi (3.1415926535) and omega (which I made up to be a string of 9s).  They have no dependencies, so they can start calculating right away.  The paren future has two dependencies, supplied as two parameters at the end of the argument list: pi and omega.  You can see that the values pi.Value and omega.Value are used in the expression, which will simply surround the concatenated string value with parentheses and spaces.

var pi = new Future<string>("pi", () => CalculatePi(10));
var omega = new Future<string>("omega", () => CalculateOmega());

var paren = new Future<string>("parenthesize", () => Parenthesize(pi.Value + " < " + omega.Value), pi, omega);

var result = new Future<string>("bracket", () => Bracket(paren.Value), paren);

Finally, the result future has a dependency on the paren future.  This surrounds the result of paren.Value with brackets and spaces.  Because the operations here are trivial, I’ve added Thread.Sleep statements to all of these methods to simulate more computationally expensive work.

The program starts calculating pi and omega concurrently, and then immediately builds the paren future, which because of its dependencies waits for completion of the pi and omega futures.  But it doesn’t block the thread.  Execution continues immediately to build the result future, and then moves on to the next part of the program.  When each part of the expression, each future, completes, it will set a Complete boolean property to true and invoke a Completed event.  Any attempt to access the Value property of one of these futures will block the thread until it (and all of the futures it depends on) have completed evaluation.

Furthermore, if an exception occurs, all of the futures that depend on it will no longer attempt to evaluate, and the exceptions will be thrown as part of an AggregateException when accessing the Value property.  This AggregateException contains all of the individual exceptions that were thrown as part of evaluating each future expression.  If both pi and omega fail, result should be able to hand me a list of all Exceptions below it in the tree structure that automatically gets formed.

There are two bits of code I added as icing on this cake.  The first is the use of the implicit operator to convert a variable of type Future<T> to type T.  In other words, if you have a Future<string> called result, you can now pass result into methods where a string parameter is expected, etc.  In the code listing at the end of the article, you’ll notice that I reference pi and omega instead of pi.Value and omega.Value (as in the code snippet above).

public static implicit operator T(Future<T> Future)
{
    return Future.Value;
}

The other helpful bit is an override of ToString, which allows you to hover over a future variable in debug mode and see its name (if you named it), whether it’s Complete or Incomplete, and any errors encountered during evaluation.

public override string ToString()
{
    return Name + ", " + (Complete ? "Complete" : "Incomplete") + (Error != null ? "Error=" + Error.Message : string.Empty);
}

What I’d really like to do is have the ability to construct this composite expression in a hierarchical form in the language, with a functionally composed syntax, replacing any parameter T with a Future<T>, something like this:

var result = new Future<string>("bracket", () => Bracket(
    new Future<string>("parenthesize", () => Parenthesize(
        new Future<string>("pi", () => CalculatePi(10))
        + " < " +
        new Future<string>("omega", () => CalculateOmega())
    ))
));

The Bracket and Parenthesize methods both require a string, but I give them an object that will at some point (“in the future”) evaluate to a string.  Another term used for future is promise, although there is a distinction in some languages that support both, but you can think in terms of giving those methods the promise that they’ll get a string later, at which time they can proceed with their own evaluation.  This effectively creates lazy evaluation, sometimes referred to as normal-order evaluation.

There are a few problems with this code, however.  First of all, though it’s composed functionally from the top down and returns the correct answer, it takes too long to do it: about 8 seconds instead of 4.  That means it’s processing all of the steps sequentially.  This happens because the future objects we’re handing to the Parenthesize and Bracket methods have to be converted from Future<string> to string before they can be evaluated in the expression, and doing that activates the implicit operator, which executes the Value property getter.  This completely destroys the asynchronous behavior we’re going for, by insisting on resolving it immediately with the wait built-into the Value property.  The string concatenation expression evaluates sequentially one piece at a time, and when that’s done, the next level up evaluates, and so on.

The solution is to declare our futures as factors we depend on at each level, which start them executing right away due to C#’s order of evaluation, and declare the operations we want to perform in terms of those predefined futures.  After a few hours of rearranging definitions, declaration order, and experimenting with many other details (including a brief foray into being more indirect with Func<Future<T>>), this is the working code I came up with:

Future<string> FuturePi = null, FutureOmega = null, FutureConcat = null, FutureParen = null;

var result = new Future<string>(
    () => Bracket(FutureParen),
    (FutureParen = new Future<string>(
        () => Parenthesize(FutureConcat),
        (FutureConcat = new Future<String>(
            () => FuturePi + " < " + FutureOmega,
            (FuturePi = new Future<string>(() => CalculatePi(10))),
            (FutureOmega = new Future<string>(() => CalculateOmega()))
        ))
    ))
);

In F# and other more functional languages, I imagine we could use let statements to define and assign these variables as part of the overall expression, instead of having to define the variables in a separate statement as shown here.

The Future<T> class I wrote works fairly well for exploration and study of futures and the possible syntax to define them and access their values, and I’ll share it so that you can experiment with it if you like, but understand that this is (even more so than usual) not production ready code.  I’m making some very naive assumptions, not taking advantage of any task managers or thread pools, there is no intelligent scheduling going on, and I haven’t tested this in any real world applications.  With that disclaimer out of the way, here it is, complete with the consuming test code.

using System;
using System.Collections.Generic;
using System.Threading;
using System.Linq;

namespace FutureExpressionExample
{
    class Program
    {
        static void Main(string[] args)
        {
            DateTime StartTime = DateTime.Now;

            Future<string> FuturePi = null, FutureOmega = null, FutureConcat = null, FutureParen = null;

            var result = new Future<string>("bracket",
                () => Bracket(FutureParen),
                (FutureParen = new Future<string>("parenthesize",
                    () => Parenthesize(FutureConcat),
                    (FutureConcat = new Future<String>("concat",
                        () => FuturePi + " < " + FutureOmega,
                        (FuturePi = new Future<string>("pi", () => CalculatePi(10))),
                        (FutureOmega = new Future<string>("omega", () => CalculateOmega()))
                    ))
                ))
            );

            /* Alternative

            // first group of expressions evaluating in parallel
            var pi = new Future<string>("pi", () => CalculatePi(10));
            var omega = new Future<string>("omega", () => CalculateOmega());

            // a single future expression dependent on all of the futures in the first group
            var paren = new Future<string>("parenthesize", () => Parenthesize(pi + " < " + omega), pi, omega);

            // another single future expression dependent on the paren future
            var result = new Future<string>("bracket", () => Bracket(paren), paren);

            */

            Console.WriteLine("Do other stuff while calculation occurs...");

            try
            {
                Console.WriteLine("\n" + result);
            }
            catch (AggregateException ex)
            {
                Console.WriteLine("\n" + ex.Message);
            }

            TimeSpan ts = DateTime.Now - StartTime;
            Console.WriteLine("\n" + ts.TotalSeconds.ToString() + " seconds");

            Console.ReadKey();
        }

        static string CalculatePi(int NumberDigits)
        {
            //throw new ApplicationException("Failed to calculate Pi");
            Thread.Sleep(3000);
            return "3.1415926535";
        }

        static string CalculateOmega()
        {
            //throw new ApplicationException("Failed to calculate Omega");
            Thread.Sleep(3000);
            return "999999999999999";
        }

        static string Parenthesize(string Text)
        {
            Thread.Sleep(500);
            return "( " + Text + " )";
        }

        static string Bracket(string Text)
        {
            Thread.Sleep(500);
            return "[ " + Text + " ]";
        }
    }

    public class Future<T> : IDisposable
    {
        public string Name { get; set; }
        public bool Complete { get; protected set; }
        public Exception Error { get; protected set; }

        protected Func<T> Expression { get; set; }

        protected List<Future<T>> Factors;
        protected List<Future<T>> FactorsCompleted;
        protected List<Future<T>> FactorsFailed;

        public event Action<Future<T>> Completed;
        protected void OnCompleted()
        {
            Complete = true;

            if (Completed != null)
                Completed(this);
        }

        private T _Value;
        public T Value
        {
            get
            {
                // block until complete
                while (!Complete)
                {
                    Thread.Sleep(1);
                }

                if (Exceptions.Count > 0)
                    throw new AggregateException(Exceptions);

                return _Value;
            }
            private set { _Value = value; }
        }

        public List<Exception> Exceptions
        {
            get
            {
                var list = new List<Exception>();

                foreach (Future<T> Factor in Factors)
                {
                    list.AddRange(Factor.Exceptions);
                }

                if (Error != null)
                    list.Add(Error);

                return list;
            }
        }

        public static implicit operator T(Future<T> Future)
        {
            return Future.Value;
        }

        // naming a Future is optional
        public Future(Func<T> Expression, params Future<T>[] Factors) : this("<not named>", Expression, Factors) { }

        public Future(string Name, Func<T> Expression, params Future<T>[] Factors)
        {
            this.Name = Name;
            this.Expression = Expression;
            this.Factors = new List<Future<T>>(Factors);

            FactorsCompleted = new List<Future<T>>();
            FactorsFailed = new List<Future<T>>();

            foreach (Future<T> Factor in this.Factors)
            {
                if (Factor.Complete)
                    FactorsCompleted.Add(Factor);
                else
                    Factor.Completed += new Action<Future<T>>(Factor_Completed);
            }

            // there may not be any factors, or they may all be complete
            if (FactorsCompleted.Count == this.Factors.Count)
                Expression.BeginInvoke(ReceiveCallback, null);
        }

        private void Factor_Completed(Future<T> Factor)
        {
            if (!FactorsCompleted.Contains(Factor))
                FactorsCompleted.Add(Factor);

            if (Factor.Error != null && !FactorsFailed.Contains(Factor))
                FactorsFailed.Add(Factor);

            Factor.Completed -= new Action<Future<T>>(Factor_Completed);

            if (Exceptions.Count > 0)
            {
                Dispose();
                OnCompleted();
                return;
            }

            if (FactorsCompleted.Count == Factors.Count)
                Expression.BeginInvoke(ReceiveCallback, null);
        }

        private void ReceiveCallback(IAsyncResult AsyncResult)
        {
            try
            {
                Value = Expression.EndInvoke(AsyncResult);
            }
            catch (Exception ex)
            {
                Error = ex;
            }

            Dispose();

            // computation is completed, regardless of whether it succeeded or failed
            OnCompleted();
        }

        public void Dispose()
        {
            foreach (Future<T> Factor in Factors)
            {
                Factor.Completed -= new Action<Future<T>>(Factor_Completed);
            }
        }

        // helpful for debugging
        public override string ToString()
        {
            return Name + ", " + (Complete ? "Complete" : "Incomplete") + (Error != null ? ", Error=" + Error.Message : string.Empty);
        }
    }

    public class AggregateException : Exception
    {
        public List<Exception> Exceptions;

        public AggregateException(IEnumerable<Exception> Exceptions)
        {
            this.Exceptions = new List<Exception>(Exceptions);
        }

        public override string Message
        {
            get
            {
                string message = string.Empty;
                foreach (Exception ex in Exceptions)
                {
                    message += ex.Message + "\n";
                }
                return message;
            }
        }
    }
}

Catch me if you can is a small library for OCaml 3.10. The latest release is version 0.2, which you may find here. This library improves management of errors in OCaml. It is released under the LGPL licence. It has been written by David Teller, Arnaud Spiwack, Till Varoquaux and Gabriel Scherer.

Long version

As all languages of the ML family -- and most modern languages indeed -- OCaml permits the management of exceptional situations using exceptions. This mechanism lets programmer register protected sections of code, as well as exception handlers to handle any exception which may be raised during the execution of a protected section. Whenever an exception is raised, the protected section of code is immediately stopped and the corresponding exception handler is executed instead. In addition, exceptions may convey some information regarding the nature of the exceptional circumstance.

In OCaml, the mechanism is fast, it's convenient and it's type-safe, much like the rest of the language (barring any type-unsafe interaction with C). However, a few things are missing. If we consider the rest of the language, exceptions are both heavyweight and clumsy: each exception must be declared before being used and there's no way to introduce a polymorphic type parameter in the exception. In addition, languages such as Java offer to important features missing in OCaml: automatic case coverage and exception hierarchies. While a nice tool exists  to provide case coverage for exceptions in OCaml, this tool is complex and  unfortunately unmaintained.

Catch me if you can offers an alternative mechanism, comparable to ML exceptions, to handle errors. In comparison with OCaml's native exception mechanism, this library adds:

• automatic inference of exceptions (i.e. no need to declare your exceptions, unless you want to)
• more flexible exceptions (i.e. exceptions may have polymorphic type parameters, constraints, etc.)
• hierarchies (i.e. an IOException is a sub-case of Exception and a super-case of NetworkException)
• case coverage (i.e. the compiler can tell you if you forgot a case or sometimes if you wrote useless ones)
• conditional success handlers (i.e. do something with the result in case of success)
• conditional success-and-failure handlers (i.e. "finally").

To attain this, we replace the mechanism of exceptions by an error monad, we replace exception constructors with polymorphic variants and we introduce a dose of syntactic sugar.

Examples

Expression evaluator

Let's write a simple expression evaluator for the following set of expressions:

[sourcecode lang='python']
type expr =
| Value of float
| Div of expr * expr
| Add of expr * expr
| Mult of expr * expr
| Subs of expr * expr
[/sourcecode]

These may be evaluated using the following function:

[sourcecode lang='python']
let rec eval = function
| Value x -> x
| Add (x,y) -> eval x +. eval y
| Mult(x,y) -> eval x *. eval y
| Div(x,y) -> eval x /. eval y
| Subs(x,y) -> eval x -. eval y
[/sourcecode]

Of course, this function is bound to fail in case of division by zero. While this is expected, there is nothing in the source code -- much less in the type of the function -- to let us know which exception will be raised in case of division by zero.

An alternative would be to add manual error checking, as follows:

[sourcecode lang='python']
type ('a, 'b) result =
| Ok of 'a
| Error of 'b

let rec eval = function
| Value x -> OK x
| Add (x,y) -> (match eval x with
| Error e -> Error e
| Ok x' -> match eval y with
| Error e -> Error e
| Ok y' -> Ok (x' +. y'))
| Mult (x,y) -> (match eval x with
| Error e -> Error e
| Ok x' -> match eval y with
| Error e -> Error e
| Ok y' -> Ok (x' *. y'))
| Div (x,y) -> (match eval x with
| Error e -> Error e
| Ok x' -> match eval y with
| Error e -> Error e
| Ok y' -> if y' = 0. then Error "Division by zero"
else Ok (x' /. y'))
| Subs (x,y) -> (match eval x with
| Error e -> Error e
| Ok x' -> match eval y with
| Error e -> Error e
| Ok y' -> Ok (x' -. y'))
(*eval : expr -> (float, string) result*)
[/sourcecode]

After this transformation, the type of the exception appears in the type of eval -- here, we used strings, but anything else would have been fine. Of course, the downside is that this is unreadable. Well, what about the following ?

[sourcecode lang='python']
let rec eval = function
| Value x -> return x
| Add (x,y) -> perform with module Error
x' <-- eval x;
y' <-- eval y;
return (x' +. y')
| Mult (x,y) -> perform with module Error
x' <-- eval x;
y' <-- eval y;
return (x' *. y')
| Div (x,y) -> perform with module Error
x' <-- eval x;
y' <-- eval y;
if y'=0. then throw "Division by zero"
else return (x' /. y')
| Subs (x,y) -> perform with module Error
x' <-- eval x;
y' <-- eval y;
return (x' -. y')
(*eval : expr -> (float, string) result*)
[/sourcecode]

This extract uses [our customized version of] Pa_monad (included in the package), which brings syntactic support for monads. While this is more verbose than the original version, it's also safer, insofar as we can guarantee that exceptions won't remain uncaught.

Still too long? Then what about using the appropriate operators?

[sourcecode lang='python']
open Error.Operators
let rec eval = function
| Value x -> x
| Add (x,y) -> eval x +. eval y
| Mult(x,y) -> eval x *. eval y
| Div(x,y) -> eval x /. eval y
| Subs(x,y) -> eval x -. eval y
[/sourcecode]

Except for the module opening, that's the same thing as our first listing. Just with the added safety.

Throwing, catching and hierarchies

By the way, the type of the result is

[sourcecode lang='python']
(*eval : expr -> (float, [> `Arithmetic of (unit, [> `Div_by_zero of (unit, _) exc ]) exc ]) result*)
[/sourcecode]

That is, eval may either succeed and return a float or fail and return an arithmetic exception, which also turns out to be a division by zero. That's classes of exceptions.

With our syntactic sugar, raising such an exception is done by

[sourcecode lang='python']
throw (exception Arithmetic (); Div_by_zero ())
[/sourcecode]

Note that we could have put some content instead of (). Note that exceptions are typed as they appear in the code and don't need to be declared (if you wonder, polymorphic variants are involved in this).

Of course, various kinds of exceptions may be combined, as in the following extract:

[sourcecode lang='python']
match ... with
| 1 -> throw (exception Arithmetic (); Div_by_zero ())
| 2 -> throw (exception Arithmetic (); Overflow "by gosh !")
| 3 -> throw (exception IO file_descr)
| ...
(*
('a, [> `Arithmetic of (unit, [> `Div_by_zero of (unit, _) exc
| `Overflow of (string, _) exc]) exc
| `IO of (int, [`> ]) exc ]) result*)
*)
[/sourcecode]

While the type of the expression is difficult to read, catching is easy

[sourcecode lang='python']
attempt ... with
| val s -> (*success*)
| Arithmetic (); Div_by_zero () -> (*Division by zero*)
| Arithmetic (); _ -> (*Other arithmetic*)
| IO _ -> (*Some IO stuff *)
| finally _ -> (*Don't forget to close the door*)
[/sourcecode]

This extract introduces three keywords:

• attempt is our replacement for try
• val is used to pattern-match against the result of a successful evaluation
• finally is used to pattern-match against the final result, whether this result was obtained after a successful evaluation or after an exception was raised and handled.

Unbreaking tail-recursion

The following extract is wrong:

[sourcecode lang='python']
let line_count filename =
let rec loop file count =
try
ignore (input_line file);
loop file (count + 1)
with
End_of_file -> count
in
loop (open_file filename) 0
[/sourcecode]

Don't get me wrong, it will compile and run. The problem is that it's not tail-recursive. In other words, it will be much slower and much more memory-consuming than if exceptions had been ignored. Why ? Because exception End_of_file may have been raised from the next call to loop, so the recursive call cannot be optimized into a non-recursive call. Of course, exceptions can't be ignored in this extract, as they are required to determine when to stop reading the file. Now, a simple transformation would make the problem go away :

[sourcecode lang='python']
let line_count filename =
let rec loop file count =
let should_continue =
try
ignore (input_line file);
true
with End_of_file -> false
in
if should_continue then loop file (count + 1)
else count
in
loop (open_file filename) 0
[/sourcecode]

Well, the transformation is simple, but it's annoying and hard to read. What's even more annoying is that it's quite common. With Catch me if you can, we would rather write the following:

[sourcecode lang='python']
let input_line2 x = Error.legacy input_line x

let line_count filename =
let rec loop file count =
attempt input_line2 file with
| val _ -> loop file (count + 1)
| _ -> count
in
loop (open_file filename) 0
[/sourcecode]

In this extract, legacy is a simple manner of wrapping an existing, one-argument, function and convert it to our new exception style. It's not quite as good as wrapping the function manually and giving it an actual exception, but it's better than nothing.

All in all, the resulting function line_count is shorter, easier to read, takes less memory and is also faster than the original.

What about performance?

Now, that's a complex question. Short answer: there's an acceptable performance loss. False short answer: we wrote a paper on that subject.

Since Java 5, the JDK comes with a concurrency library that makes concurrent programming a lot easier than it used to be, and the library has been improved further in Java 6. This provides some basic abstractions that take care of the nitty-gritty of thread management for us. In this short series of articles, I'm going to show how we can build on top of that library to achieve concurrent programming of a higher order. We will employ some design patterns and simple abstract building blocks from functional programming. This style of writing concurrent programs will afford us the ability to:

• Compose ordinary functions into concurrent programs.
• Decouple parallel behavior from the algorithm itself.
• Turn existing code into parallel code, without refactoring, at runtime.
• Work with hypothetical results of concurrent computations, before they finish.

We will not use any locking or explicit synchronization. Basic familiarity with the java.util.concurrent package is assumed but not required. Familiarity with generics is highly recommended, and I recommend reading parts 1 and 2 of my Lazy Error Handling series as it explains some preliminaries. Most of the source code herein is already part of the Functional Java library, and I'll use a fair bit of interfaces and classes from it, which I'll introduce as we go along.

When we're through, I will have demonstrated that a functional style of programming promotes code-reuse and modularity of parallel programs, above and beyond what can be achieved with the canonical object-orientated style.

The Callable Monad

The Callable interface is new in Java 5. It's similar to the old Runnable interface that we all know and love, except that its call() method returns a result, and it may throw an Exception. If you followed my Lazy Error Handling articles, you will immediately notice that Callable is nearly identical to the Thrower interface described in that series, and you'll know that it is indeed a potential monad. Treating Callable as a monad will allow us to work with it at a higher level of abstraction, letting us compose Callables, chain them, and project computations into them.

As you may already know, we need three ingredients (and only these three) to have a monad:

1. Type construction. This comes free with the Callable interface, since it takes a type parameter (i.e. it's generic).
2. A unit function. This allows us to turn any value into a Callable that returns that value again.
3. A binding function. This allows us to chain together Callables with functions, without actually calling them.

Here is the unit function for Callable (we will refer to it as unit in the text to avoid ambiguity):

  public static <A> Callable<A> callable(final A a) {
    return new Callable<A>() {
      public A call() {
        return a;
      }
    };
  }

And here is its binding function:

  public static <A, B> Callable<B> bind(final Callable<A> a, final F<A, Callable<B>> f) {
    return new Callable<B>() {
      public B call() throws Exception {
        return f.f(a.call()).call();
      }
    };
  }

Note: The F interface is from Functional Java. It represents a first-class function (a function that can be treated like any other value). F<A, B> has one method that takes an argument of type A and returns a value of type B.

Given the above two methods, Callable is now a monad. All monads are also functors, so we can define a Callable functor. What I mean by "functor" is that we can define a method to turn any existing function into a function on Callables, or, in other words, to apply any function to a value wrapped in a Callable, without actually calling it (i.e. lazily). This method is called fmap, and we can define it in terms of bind:

  public static <A, B> F<Callable<A>, Callable<B>> fmap(final F<A, B> f) {
    return new F<Callable<A>, Callable<B>>() {
      public Callable<B> f(final Callable<A> a) {
        return bind(a, new F<A, Callable<B>>() {
          public Callable<B> f(final A ab) {
            return new Callable<B>() {
              public B call() {
                return f.f(ab);
              }
            };
          }
        });
      }
    };
  }

Useful operations on Callables, that the methods above allow us to implement, include sequence---which is a method of turning a list of Callables into a single Callable that returns a list---and join, which peels one layer of Callables from a Callable<Callable<A>> so that it becomes just Callable<A>. You will find the source code for those as part of Functional Java.

Parallel Strategies

When working with the java.util.concurrent library, you normally don't work with Threads directly. You might instead implement Callable<A> and submit instances of your implementation to an ExecutorService, which yields values of type Future<A> which represents a running computation that yields an A. Future has a method called get() that returns the result as soon as it's ready. This is a great improvement over managing threads and Runnables ourselves, but it still ties our hands somewhat to the ExecutorService, and encourages tight coupling of our code to the parallelisation library.

Inspired by Haskell's "Parallel Strategies", let's instead work with parallelisation in the abstract. For what is ExecutorService, really? It's a method of turning Callables into Futures. That means it's a kind of function, so we can abstract from it, using a function type: F<Callable<A>, Future<A>>. Such a function can then be backed by an ExecutorService, or by something else entirely, such as a load-balancing facility that serializes Callables to be executed on remote servers.

We will use a new class, Strategy<A>, that allows us to effectively separate parallelism from the algorithm itself:

  public final class Strategy<A> {

    private F<Callable<A>, Future<A>> f;

    private Strategy(final F<Callable<A>, Future<A>> f) {
      this.f = f;
    }

    public F<Callable<A>, Future<A>> f() {
      return f;
    }

    public static <A> Strategy<A> strategy(final F<Callable<A>, Future<A>> f) {
      return new Strategy<A>(f);
    }

  }

We'll add a couple of static functions to create simple strategies:

  public static <A> Strategy<A> simpleThreadStrategy() {
    return strategy(new F<Callable<A>, Future<A>>() {
      public Future<A> f(final Callable<A> p) {
        final FutureTask<A> t = new FutureTask<A>(p);
        new Thread(t).start();
        return t;
      }
    });
  }

  public static <A> Strategy<A> executorStrategy(final ExecutorService s) {
    return strategy(new F<Callable<A>, Future<A>>() {
      public Future<A> f(final Callable<A> p) {
        return s.submit(p);
      }
    });
  }

One of the neat things that working with Strategies as functions allows us to do is use the Callable monad to compose them with existing functions. Any function can be lifted into the Callable monad using fmap, and then composed with a Strategy to yield a concurrent function. Moreover, we can use Strategies to convert existing functions to concurrent functions. The following method on Strategy will take any function and return the equivalent function that executes concurrently. Calling such a function will give you a Future value from which you can get the computed result whenever it's ready.

  public <B> F<B, Future<A>> lift(final F<B, A> f) {
    final Strategy<A> self = this;
    return new F<B, Future<A>>() {
      public Future<A> f(final B b) {
        return self.f().f(new Callable<A>() {
          public A call() {
            return f.f(b);
          }
        });
      }
    };
  }

Alert readers will note that lift represents the Kleisli arrow for the Future monad. As for most monads, this arrow is a very useful kind of thing (see Lazy Error Handling, Part 2). In the Future monad, the Kleisli arrow provides parallel function application. If you already have a function f, then calling lift(f).f(x) will apply that function to x while simultaneously continuing with the next statement in the current program.

Lazy Futures

For functions involving Futures, we generally always want to have the Future type in the codomain (on the right-hand side, in the return type). If you think about it, you'll see that functions that take Futures in their arguments won't be able to do much without blocking on Future.get(). However, that doesn't mean we can't compose Future-valued functions together. It just means that we can only compose two of them together in such a way that we either wait for the first Future to obtain a value before firing off the second one, or we have to spark a new thread that does nothing but wait on the first Future. We're much better off composing Callables and then turning those into Futures as needed. In fact, we might want to wrap values of type Future<A> inside of a Callable<A> again so that we can manipulate their return values while they are running:

  public static <A> Callable<A> obtain(final Future<A> x) {
    return new Callable<A>() {
      public A call() throws Exception {
        return x.get();
      }
    };
  }

And this takes us full circle back into the Callable monad, where we can compose computations, bind them to functions and map functions over them, all lazily. Which means: without actually asking what their values are until we absolutely need to know.

So we have accomplished what we set out to do in this first part of the series. We've written a Callable monad that lets us compose existing code into concurrent programs. We've implemented parallel strategies to run those programs in parallel, without regard to the actual parallelisation implementation. We have a Kleisli arrow that lets us run ordinary functions concurrently with each other, and finally we have a way of taking concurrently running computations back into the Callable monad. Not bad for a day's work.

In the next part of this series, we will employ what we've built here to develop some higher-order parallel functions, including a parallel list functor. I hope you join me.

1. The merge() function does not use an accumulator argument any more and is indeed much simpler now.
2. The recursive mergesort_ function now does not use the haskell list length operator any more. Instead, the length of the list to be sorted is passed down the recursive chain.

Please see the optimised mergesort implementation for details.

These improvements reduced the RAM utilisation and improved the run-time performance by another 20% respectively.

Nothing to scoff at, eh?

Their advice was to use byte strings as opposed to normal strings since the former perform much better.

I tried that and observed that the RAM utilisation and run-time went down by approximately 85% !

The reduced RAM utilisation was attributed to the more efficient byte strings and the improved run-time performance to the reduced garbage collection overhead respectively.

The difference between the source files (mergesort.hs, Scaffolding.hs) is minimal and switching over to byte strings was facilitated by the fact that they expose the same interface as normal strings.

Nice!

The resulting code (sans command line parameter handling, auxiliary I/O functions etc.) is quite neat and was written in little time. Haskell is very expressive and its attractiveness immediately obvious when formulating pseudo-mathematical problem solutions.

  1 module Main(main) where
  2 
  3 import qualified IO
  4 import System(getArgs)
  5 import Monad(mapM_)
  6 import qualified Scaffolding
  7 
  8 mergesort l =
  9     if (length l) <= 1 then l -- The list is already sorted.
 10     else -- Split the list into two halves and sort these.
 11         merge (mergesort lpart) (mergesort rpart) []
 12         where llen_half = (length l) `div` 2
 13               (lpart, rpart) = splitAt llen_half l
 14 
 15 -- Case #1: the right list is empty; just append the left list to the
 16 -- accumulator. The latter is reversed because we were prepending
 17 -- to it in case #3.
 18 merge lpart [] acc = (reverse acc) ++ lpart
 19 
 20 -- Case #2: the left list is empty; just append the right list to the
 21 -- (reversed) accumulator list.
 22 merge [] rpart acc = (reverse acc) ++ rpart
 23 
 24 -- Case #3: neither of the left/right lists to be merged is empty;
 25 -- prepend the lesser head element to the accumulator list.
 26 merge (l:ls) (r:rs) acc =
 27     if l <= r then merge ls (r:rs) (l:acc)
 28     else merge (l:ls) rs (r:acc)
 29 
 30 -- The main method, handles command line arguments, input and output.
 31 main = do
 32     args <- getArgs
 33     fileh <- case head args of
 34                 -- The text to be sorted is to be read from stdin.
 35                 "-" -> do return (Just IO.stdin)
 36                 -- The text to be sorted is to be read from the file
 37                 -- specified.
 38                 "-f" -> do Scaffolding.openFile (head (tail args))
 39                 -- Just sort the command line parameters.
 40                 _ -> do let sorted_args = mergesort args
 41                         IO.putStrLn ("mergesort(" ++ show args ++
 42                                      ") = " ++ show sorted_args)
 43                         return Nothing
 44     case fileh of
 45         -- Read text from file handle, sort it and print to stdout.
 46         Just fileh -> do text_to_sort <- Scaffolding.readLines fileh []
 47                          mapM_ IO.putStrLn (mergesort text_to_sort)
 48         -- We failed to open the file specified (if any).
 49         Nothing -> do return ()

I also liked the fact that the haskell standard library is rich and nicely documented.

Just to get an idea of how my naive mergesort implementation performs I created a file listing all the files on my Dell D630 laptop running Hardy Heron (please ignore the recursive nature of this problem :-) ).

 1 u804: haskell $ ghc --version
 2 The Glorious Glasgow Haskell Compilation System, version 6.8.2
 3 u804: haskell $ ls -l all-files.txt
 4 -rw-r--r-- 1 mhr mhr 26245382 2008-05-31 17:18 all-files.txt
 5 u804: haskell $ wc -l all-files.txt
 6 399754 all-files.txt
 7 u804: haskell $ uname -a
 8 Linux u804 2.6.24-18-generic #1 SMP Wed May 28 20:27:26 UTC 2008 i686 GNU/Linux

I then let loose the compiled haskell binary on that file (all-files.txt) and compared how it performed against /usr/bin/sort.

  1 u804: haskell $ time ./mergesort -f all-files.txt >/dev/null
  2 
  3 real    0m12.994s
  4 user    0m12.349s
  5 sys 0m0.632s
  6 u804: haskell $ time sort all-files.txt >/dev/null
  7 
  8 real    0m10.675s
  9 user    0m10.613s
 10 sys 0m0.052s
 11 u804: haskell $ time sort all-files.txt >/dev/null

The difference in performance was moderate (22%) given that I did not tune the haskell implementation in any way.

However, I gasped when I observed the RAM utilisation while the haskell program was running: it used 726 MB of RAM!

Compare this to 34 MB that were used by the standard sort program.

I guess it's time to get acquainted with ghc -prof and friends :-)

Last but not least I'd like to point to a great haskell resource, the Real World Haskell beta book.

First, let's examine what exceptions really are. During the evaluation of some expression (some function), unexpected conditions or data are encountered, with which it is undefined how to proceed. That is to say, for some inputs, the result of the computation is undefined. For example, when a parseInt function encounters a character that isn't a digit (or a minus sign), what do we do? Well, we don't know exactly, so we need some way to indicate failure. It would be invalid to return an integer. One could return null, but that isn't exactly reliable, nor correct, and well, it would be lying since the type signature promises an integer.

So far, I've shown how we can use a Thrower monad to indicate that a computation can error. But the Thrower monad doesn't do anything except wrap Java's existing exception handling with a datastructure. And what do you think Java's existing error handling is? It's a monad. No, really, it is. In fact, Java is one big monad with bells on.

Note that throws changes the type of a method so that it may throw exceptions. Sound familiar? That's what Thrower does (see part 1). Java's throws keyword is the Kleisli arrow (see part 2) for Java's exceptions functor. Binding is done with a combination of try and a Java keyword called ";" which I'm sure you use all the time without even batting an eye. You can then think of catch as a function that takes a monadic value and "extracts" from it, performing case analysis on the result.

Why did we need Thrower then? The difference is that throws needs to be hard-coded at method definition time, while our Kleisli arrow, which we called Partial, transforms function values "at runtime".

Returning Errors

We now find that we can take this idea further. We don't actually need the throws monad at all, and hence, we don't need Thrower either. Don't get me wrong. I like the Trower monad. I use the Thrower monad in production. But let's explore what we can do to approach a more functional style of error handling, just for grins.

Instead of throwing Exceptions, we can just collapse error types into the return type. We'll use a monad called Either, which looks very similar to Thrower except that errors are returned, not thrown. The Functional Java library luckily has Either already defined:

  public abstract class Either<A, B>

Either is the disjoint union of two types. A value of type Either<A, B> simply wraps a value of either type A or type B. The Either class comes with two static data constructors:

  public static <A, B> Either<A, B> left(final A a)

  public static <A, B> Either<A, B> right(final B b)

We'll use the standard convention that left values represent failure, and that right values represent success.

Let's see how we might use this data type for error handling. It's really quite straightforward. The following declares the return type of parseInt to be either an Exception or an Integer (the left value can actually be any type, but... baby steps).

  public Either<Exception, Integer> parseInt(String s);

Oh, but wait. We've lost the laziness. Functional Java's Either, by itself, is not lazy like Thrower is. If we do want laziness, we have to wrap the computation in a closure. For example, we can use fj.P1, which is just a generic interface with one method _1() which takes no arguments.

  public P1<Either<Exception, Integer>> parseInt(String s);

That's better. Raising errors is done by returning a left value:

  return new P1<Either<Exception, Integer>>() {
    public Either<Exception, Integer> _1() {
      return Either.left(new Exception("You broke it!"));
    }
  };  

Sometimes you're able to call functions that might fail, recovering with a default value:

  P1<Either<Exception, Integer>> a = parseInt(s);
  int addFive = (a._1().isLeft() ? 0 : a._1().right().value()) + 5;

Other times, you will be catching exceptions thrown by other people's code and converting them to Either:

  public static P1<Either<Exception, Double>> divide(double x, double y) {
    return new P1<Either<Exception, Double>>() {
      public Either<Exception, Double> _1()
        try {
          return Either.right(x / y);
        } catch (Exception e) {
          return Either.left(e);
        }
      }
    };
  }

An error is sent to the caller simply by returning it. In the example below, the parse errors are explicitly caught and re-raised, while any errors raised by the divide method are implicitly returned.

  public static P1<Either<Exception, Double>> parseAndDivide(String sx, String sy) {
    final P1<Either<Exception, Integer>> x, y;
    x = parseInt(sx); y = parseInt(sy);
    return new P1<Either<Exception, Double>>() {
      public Either<Exception, Double> _1() {
        if (x.isLeft() || y.isLeft()) {
          return Either.left(x.isLeft() ? x.left().value() : y.left().value());
        }
        return divide(x.right().value(), y.right().value());
      }
    };
  }

Either is a monad, so we can lift existing functions into it, compose Eithers, sequence them, just like we did with Throwers. Here I'm taking an existing sine function and reusing it for values of type Either<Exception, Double>:

  F<Double, Double> sin = new F<Double, Double>() {
    public Double f(final Double a) {
      return Math.sin(a);
    };}

  P1<Either<Exception, Double>> z =
    divide(x, y).map(Either.rightMap_().f(sin));

If you need to work with more than one kind of error at a time, you can. Simply nest them on the right, like so: Either<E1, Either<E2, A>>. This is something we could not do with Thrower.

Nothing to Declare

Now, we've been returning Exceptions, but what does an Exception give you, really? You get some information about the failure, like an Exception type name, an error message, a stack trace, and possibly a nested Exception. If you know how to recover from an error, are you going to need the stack trace and the error message? No. You don't actually have to return Exceptions to indicate errors if you don't want to. You could just as well return String, Integer, fj.Unit, or your favourite data structure. Or you could return... Nothing.

There's a simpler monad than Either which is often used in functional programming. It's called Option (sometimes known as Maybe). An example is Functional Java's fj.data.Option class, which I'll demonstrate briefly here. Option<A> is a lot like a List<A> that can either be empty, or contain a single value of type A. For example:

  public static Option<Double> divide(double x, double y) {
    if (y == 0) {
      return Option.none();
    }
    return Option.some(x / y);
  }

This is similar to returning null on failure, except that callers won't be surprised if the method fails to return a value. It's declared in the method signature, after all. Option.none() has the correct type and will respond to methods declared on the Option class. If you want a lazy Option, simply wrap it in a P1 like we did with Either.

Not surprisingly, Option comes equipped with monadic methods like fmap (or simply "map") to lift an F<A,B> to an F<Option<A>, Option<B>>, "bind" to chain Option-valued functions together, and "join" to collapse an Option<Option<A>> into an Option<A>. Option's unit function is the static method Option.some. The instance method some() returns the value in the Option, if any. This last one is the Option equivalent to Thrower.extract().

So, now that we're using Option and Either to indicate recoverable errors, what about unrecoverable errors? Those are the kinds of errors that we're not going to catch, nor expect any reasonable application to catch. They should result in immediate and visible failure. For example, we might decide that it's not reasonable to recover from a critical function if it returns nothing:

  Option<MyAppConfig> config = getAppConfig();
  if (config.isNone()) {
    throw new Error("No configuration!");
  } else {
    // Do stuff with config here.
  }

At this point, we have completely obviated Java's checked exceptions mechanism. Recoverable errors are simply returned, and unrecoverable errors are thrown all the way out. We can now construct computations, and even if they might fail we can pass them around, compose them together, extract values from them, etc. All without a throws keyword in sight. The circle is complete.

That's the end of Lazy Error Handling in Java. We've gone everywhere from throwing exceptions lazily, to higher-order chaining and manipulation of exception-throwing computations, to doing away with checked exceptions altogether. I hope you have found this short series educational and as fun to read as it was to write.

END

In this post, we'll see that the greatest benefit of Thrower is the ability to compose and sequence computations; even computations that may fail, all the while staying type-safe. We'll introduce some new functions which allow us to perform a kind of Thrower arithmetic that in turn will let us manipulate values tucked away in Throwers, without ever having to extract from them, and without any exceptions being thrown or caught.

The ingredients we need are exactly the ingredients needed for a monad. That is: A type construction, a unit function, and a binding operation. The first ingredient, type construction, we already have. The Thrower interface is generic, so it lets us create a type Thrower<A, E> for any type A, given some Throwable type E.

The unit function is simple enough. It just creates a new Thrower that completely preserves the value that we put in it:

  
  public static <A, E extends Throwable> Thrower<A, E> unit(final A a) {
    return new Thrower<A, E>() {
      public A extract() {
        return a;
      }
    };
  }

The final ingredient for our Thrower monad is the bind function. It takes a Thrower and feeds its result to a function that returns another Thrower:

  
  public static <A, B, E extends Throwable> Thrower<B, E>
  bind(final Thrower<A, E> a, final F<A, Thrower<B, E>> f) {
    return new Thrower<B, E>() {
      public B extract() throws E {
        return f.f(a.extract()).extract();
      }
    };
  }

Check what this actually does. It creates a new Thrower, whose extract() method calls the extract() method on the first Thrower and applies the function f to the result. Nothing actually happens when we call bind, except that a new future call to the provided function is created. So we're applying f to the contents of the Thrower a, but not suffering any consequences until later, whenever we decide to call extract() on the result of bind.

Note that we can only compose, in this manner, Throwers that throw the same Throwable type. To combine Throwers of different kinds of exceptions, you would need to return a Thrower<Thrower<A,E1>,E2>>, or something like a Thrower2<B,E1,E2> which can throw either E1 or E2. You cannot create a new generic Throwable like MyException<E1, E2> as the disjoint union of two Throwables, since subclasses of Throwable are not allowed to be generic due to Java's runtime type erasure. Normally, I don't care about the types of exceptions to that level of detail anyway, so if I need to work with different species of them, I just use the Exception type. That's exactly what we'll do in the example further down.

Now, notice the second argument to bind:

          
  final F<A, Thrower<B, E>> f

This is a pretty useful kind of thing. It's a function that takes an A and either returns a B or throws an E. So it's kind of like a Thrower that takes an argument. It's actually a Kleisli Arrow for the Thrower monad. This is something we'll need often, so let's make them easy for ourselves to create:

  
  public abstract class Partial<A, B, E extends Throwable> implements F<A, Thrower<B, E>> {

  protected abstract B run(final A a) throws E;

    public final Thrower<B, E> f(final A a) {
      final Partial<A, B, E> self = this;
      return new Thrower<B, E>() {
        public B extract() throws E {
          return self.run(a);
        }
      };
    }
  }
   

It's called Partial because it models a partial function, a function whose result is undefined for some values (i.e. it might throw an exception instead of returning a value). We've abstracted away all the Thrower stuff (it's always going to work the same anyway), so concrete subclasses will only have to override the run method and do what a partial function would: turn an A into a B or throw an E.

It might seem that this has taken us full circle, that this was all an exercise in futility if we're back to just writing methods that throw exceptions. But no, what we have so far actually gives us a lot of power under the hood.

For the token contrived example, let's say that you have an abstract class which models an action to get some object from the network given a URLConnection, possibly throwing a network error:

    
  public abstract class NetTalker<A> extends Partial<URLConnection, A, Exception> {}

Even though this class has no body, its intent is very clear. Users of our API will just have to to override run to do something useful with a connection. But NetTalkers just use connections; the construction of URLConnections will be implementation-specific. We'll use another class:

  
  public abstract class URLConnector extends Partial<URL, URLConnection, Exception> {}

Where concrete subclasses create different concrete URLConnections. To get an A from a URL, given some URLConnector c (that knows how to make HttpURLConnections) and some NetTalker n, we can do the following:

          
  Thrower<A, Exception> t = bind(c.f("http://foo.bar"), n);

Again, this doesn't give you the object of type A, it merely gives you a Thrower which either returns the A or throws an exception. It's lazy. You can take t and bind it to a Partial that takes an A and, say, writes it to a file, again returning a lazy Thrower. Then, when something calls extract() on it, the whole enchilada of operations will be executed in one go.

Or, if you have a whole list of Throwers, you could turn them into a Thrower that returns a list:

  

  public static <A, E extends Throwable> Thrower<List<A>, E> sequence(final List<Thrower<A, E>> ts)
  {
    return ts.foldRight(Throwers.<List<A>, E> unit(List.<A>nil()),
      Throwers.<A, List<A>, List<A>, E> liftM2(List.<A> cons()));
  }

The above collapses an entire list of throwers into a single thrower that returns all their results in one list. Here, List is a fj.data.List from Functional Java, not java.util.List, although this can be made to work quite easily with the Java Collections Framework by defining nil(), cons(), and foldRight(). liftM2 is almost exactly like fmap from Part 1, except that it lifts functions of arity-2.

We've only had a slight taste of what we can do with monads, even in Java, and there are relationships between fmap, bind, and unit that are worth understanding in detail. As you can see, it's a powerful abstraction that can be applied to a wide variety of problems. It doesn't stop with Throwers. Notice that NetTalker is also a generic type, with a single type parameter. Yes, it too is a functor. It too can be a monad, and can be composed as we did with Throwers. In fact, here's fmap for NetTalker:

 
  public static <A,B> F<NetTalker<A>, NetTalker<B>>
    fmap(final F<A,B> f) {
      return new F<NetTalker<A>, NetTalker<B>>() {
        public NetTalker<B> f(final NetTalker<A> a) {
          return new NetTalker<B>() {
            public B run(URLConnection u) throws Exception {
              return f.f(a.f(u));
            }
          };
        }
      };
    }

I wonder what other types are monadic.

Unfortunately, you'll find that you can't write a generic Monad class in Java. Poor Java's type system is not sophisticated enough to understand higher-kinded types, nor would that be sane without type inference in the compiler, which Java also lacks. You will have to write bind and unit for every kind of monad that you need, as well as all operations based on them (fmap, sequence, etc.), or dispense with the type system (in which case you may as well be writing Ruby), or switch to Scala.

I hope you enjoyed this little journey through monads and exceptions in Java. In Part 3 of this series, we will look at how we can remove try, catch, and throws entirely from our code, in favor of unit, bind, fmap, and join.

The world’s most common extension method and an attempt at a definitive version.

In this post I'll be digging deeper into doing things I've always wanted to have in .NET yet didn't. For example, I know I am not alone in wanting an IList (be it an IList<T> or a simple non-generic IList) to provide me a .foreach method as you get in a List<T>). This is just one of many things we address here (and more).

From the concrete to the abstract

I was having problems with entries in my path environmental variable, and I wanted an easy way to flag bad entries and also allow me to move the entries in the list up or down easily. This was made apparent by my use of a tool called 'Dependency Walker'. It's hard to live without but that's another post. See the screen shot below:

Click here to go to 'Dependency Walker'

Test to Code