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.

Caml Trading

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.

We switched over to using Mercurial about a year and a half ago (from tla/baz---don't ask), and it's worked out quite well for us. One of the key issues we ran up against is how to come up with a reasonable workflow, one that allowed people to work independently when they needed, and also included an effective central coordination point.

In a recent post, I described some of the problems associated with OCaml's built in polymorphic comparison functions. So, if you want to avoid OCaml's polymorphic compare, what are your options?