I'm pleased to announce that we now have ocamldoc generated documentation available for Type-conv, Bin-prot, Sexplib, and Core. You can find them here:

http://www.janestreet.com/ocaml/janestreet-ocamldocs/

The module paths in the documentation for Core and Core_extended are relative to Core.Std and Core_extended.Std

You can also find a tarball here:

http://www.janestreet.com/ocaml/janestreet-ocamldocs-2009-11-11.tgz

This post is meant to be the first in a series highlighting various interesting features of Core (although I should acknowledge that most of the continuing series I've started so far have not, when it comes down to it, continued.) This time I wanted to focus on how Core handles time.

With the latest release of Core, I've had occasion to think about how our libraries differ from INRIA's. One difference that's been there from the very beginning is in the List module: INRIA's list functions are not tail-recursive, and ours are.

We are proud to announce the second major release of Core, Jane Street's alternative to OCaml's standard library. This release also includes Core_extended, which adds new functionality such as subcommand style command line argument handling, a procfs interface, readline support, and more. Core_extended is used heavily at Jane Street, but not systematically code reviewed in the same manner as Core.

Just thought I should point out another post, this one from Patai Gergely, summarizing events at the JSSP end-of-summer meeting, this one including pictures!

We just had the end-of-summer meeting for this year's JSSP, and this is my personal summary of the event. We expect to post more information in the next few days, including videos of the talks and photos.

From my point of view, the single most useful project is unquestionably ocamlviz. Ocamlviz is a realtime profiling tool for OCaml, and I was really impressed with the system's polish.

One of the key decisions to make when designing a code review system is choosing the basic unit of code review. One approach common in many open-source projects is to be patch-centric, i.e. to make the reviewable unit a single patch. In a patch-centric world, code review is complete when every patch that went into the system has been read.

We instead decided to build tools that were diff-centric. In a diff-centric world, reviews aren't done on single patches, but instead between a pairs of points in history. Code review is complete when a path of diffs has been completed, starting from a fully read revision, and ending in the revision to be approved.

We've just rolled out a new software tool for managing our code review process. Code review is a pretty central part of how we try to maintain a high level of quality and safety for our critical software systems, and so a code review management tool is an essential and long-overdue piece of infrastructure for us.

The new system is meant to facilitiate the basic code review process we've been using, and at the same time make it more flexible and scalable. Before this tool, our approach to reading code was pretty simple.

It might be surprising to hear that there are a significant number of OCaml users in Japan, but it is true. OCaml has been used in programming courses of several major Japanese universities for several years.

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':