At least, if you ask with a nicely detailed bug report. Looks like the missed optimization for equality on polymorphic variants I mentioned in a previous post has been fixed. It will be interesting to see what effect this has on our codebase...

I have a love-hate relationship with OCaml's polymorphic comparison functions, which I think I share with a lot of people who use the language. For those who don't know what polymorphic compare, a quick explanation. OCaml has a collection of functions for comparing values which, magically enough, can be used on virtually any data type. For example, there is a comparison function in Pervasives with the following signature:

 
val (>=) : 'a -> 'a -> bool

If you stop to think about it, this is a pretty surprising little function. How does one write a single function to compare ints or floats or lists or any random type cobbled together out of records, tuples, and variants?

A couple of months ago, Pascal noticed some missed optimizations in OCaml's float unboxing optimizations. In some cases, code that looked like it should be compiled down to a sequence of allocation-free floating point operations turned out to involve quite a lot of allocation, with floats getting boxed and then immediately unboxed for no purpose. The fact that the compiler missed this particular optimization forced us in a few spots to do some ugly manual inlining, and generally made us sad.

But we are sad no more! We filed a bug report, and it just got fixed in OCaml's CVS. You can see the details here. Now all we're waiting for is a fix to the missed optimization for equality on polymorphic variants.

One of the best features of ML is pattern matching. Pattern matching is essentially a way of writing a case analysis driven by the structure of the data. The thing that makes pattern matching such a phenomenal tool is the type-checking discipline that is associated with it. In particular, the compiler checks that pattern matches are exhaustive and non-redundant. This is helpful when writing a case analysis for the first time, but the value of the technique really shows itself as the code evolves.

This article deals with some not well-known dark corners of the OCaml compiler and how to get around them to produce more efficient code. The bottom line is that you should avoid using partial applications and instead prefer eta-expanding your functions to the maximum.

Here's a little trick that I find useful when I get a type error due to a function that I believe is polymorphic, but isn't due to some bug.

This is intended to be the first in a series of posts talking about the design principles behind core, Jane Street's alternative to OCaml's standard library.

It's worth noting that we haven't quite fully achieved any of our design goals. Core is at the center of a complicated and evolving software infrastructure, and it takes longer to force changes through that infrastructure that it does to figure out what changes should be made. So these principles serve as both a guide to how the library is currently laid out as well as an indication of what kinds of changes are likely to come over the next year or so.

We are proud to announce the first public release of core, Jane Street's own alternative to OCaml's standard library. We use this library as the base for our own development, and we hope people on the outside will find some use for it as well.

Here's a type-checking problem I ran into today. I had a module with a variant type matching a signature that exposed the variant type.

module type S = sig
  type t = A | B
end
 
module M : S = struct
  type t = A | B
end

I wanted to extend the module with some new functions, and match a new signature that extended the original signature. Easy, right?

Unlike let declarations, type declarations in OCaml are automatically recursive. This seems harmless at first, but it actually causes more trouble than it's worth. To see why, let's look at an example.