One of my favorite features of the Hindley-Milner type system is the built-in exhaustiveness checking that is applied to pattern matches. I like this feature enough that it is the focus of the only worked-out example I give in my talk about OCaml at Jane Street.

Why is exhaustivenss checking so important? You can slog through my talk if you want to hear a fuller account, but the basic point is that case analysis is one of the most common things one does in any program, and anything that can statically check important properties of your case analysis is really helpful. Moreover, exhaustiveness checking serves as a kind of refactoring tool. Whenever you expand the possibilities in a type, the compiler will point you to the places where you forgot to handle the new cases you just created. It is, from the perspective of someone who has programmed in ML for a living for some years now, an enormously useful feature.

So I was quite taken aback when one of our interns here (who will remain nameless, in case I've horribly misconstrued his words) pointed out to me that Haskell by default doesn't even warn the programmer about inexhaustive pattern-matches. In particular, if you save the following code into a file called 'foo.hs':

This year's JSSP projects have been selected. We think it's an exciting list of projects, and we're pleased that this year the projects support a number of different programming language communities outside of OCaml. Here's the list, along with abstracts:

The application period for this year's summer project is now closed, and we have an interesting collection of proposals to choose between. The proposals use a number of languages (in particular, Scheme, SML, F#, Haskell and OCaml), looking to address a wide variety of different problem types.

We'll get out acknowledgments to everyone who sent in a proposal within the next couple of days.

I was at CMU several weeks ago, and gave a version of my "Caml Trading" talk there. See below if you are interested in seeing the video. It's a reasonably good source if you're interested in understanding more about how and why Jane Street uses OCaml.

If you do, you might want to consider submitting a proposal to the 2009 CUFP (Commerical Users of Functional Programming) workshop.

CUFP brings together people from different industries who use different languages, where the common thread is the use of FP in a practical setting. And it's been a quite vibrant event, attracting many interesting talks, and growing quite quickly, going from 25 registered participants in '04 to over 100 in '08.

It's worth noting that CUFP isn't just about commercial use, despite the name. It's meant for anyone who is using functional programming as a means rather than an end.

I'm having a lot of trouble figuring out what private type abbreviations are good for. Private type abbreviations arrived as a new feature in OCaml 3.11, but I still don't know where I would want to use them.

I am pleased to announce the Jane Street Summer Project for 2009! The goal of the program is to encourage growth in the functional programming community. To do that, we will fund students over the summer to work on open-source projects aimed at making functional languages into more effective and practical tools for programming in the real world.

At Jane Street, we often write OCaml programs that communicate over the network with each other, and as such, we need to build lots of little protocols for those programs to use. Macro systems like sexplib and binprot make the generation of such protocols simpler. The basic workflow is to create a module that contains types corresponding to the messages in the protocol. Macros can then be used to generate the serialization and deserialization functions. Just share the protocol module between the different programs that need to communicate with each other, and --poof-- you have a protocol.

I've been meaning to write about the OCaml Summer Project end-of-summer meeting that occurred on September 12th, but as those of you who read the news may have noticed, it's been a busy time in the financial markets. But I've gotten a moment to catch my breath, so I thought I'd post my recollections.

Parametric polymorphism is a basic mechanism in ML for writing code that is generic, i.e., that can be used on multiple different types. To get the basic idea of how what parametric polymorphism is, think about the following simple example.

module M : sig
  (* Takes a list and returns a stuttered version, e.g., [1;2;3]
     is mapped to [1;1;2;2;3;3] *)
  val double : 'a list -> 'a list
end = struct
  let rec double = function
     | [] -> []
     | hd :: tl -> hd :: hd :: double tl
end

In the type signature for double, the expression 'a is a type variable, meaning that this function can be used with an arbitrary type plugged in for 'a. The reason that the type variable shows up is that the code of double doesn't depend in any way on the properties of the elements of the list.