Logo OS Reviews

Reviewing Freedom.


Objective Caml

Advanced Functional Programming

Florian Weimer


Print version

Slashdot me! Digg me! Stumble me! del.icio.us

After playing around with Standard ML (SML), a functional programming language, I started to like the concepts: compile-time type checking, closures, exceptions, finalization and efficient bit manipulation (at least in MLton). MLton additionally offers a quite usable interface to C libraries. What's missing, however, are real applications written in SML. Sure, there are some proof generators and of course the SML implementations themselves, but these are all niche products and tell little about its qualification for production use. What's even worse, the various SML implementations don't see much further development. So it seems that development with SML may be fun, but you might end up with an development system with no vendor or community support.

Objective Caml is a programming language that is derived from pre-Standard ML. Nowadays, it is still conceptually related to SML, however there are several syntactical deviations. The standard library of course is totally different, too.

If you are used to SML, the Objective Caml syntax feels at first a bit like lower class programming. Of course, that's not really true, but SML may be a bit more elegant. The Caml syntax is typical for the ML languages and therefore highly counterintuitive if you've only seen something like C, Lisp or Python before.

Similar to Perl or PHP the name "Objective Caml" represents both the programming language and the implementation. Contrary to the well-known scripting languages, there is both a compiler for its virtual machine and a compiler for native code.

How does Objective Caml perform compared to the pros and cons for SML mentioned in the beginning? Static type checking, closures, exceptions, byte arrays with efficient access are all available. The implementation is being actively developed (maybe not to the extent of, say, GCC) and its development model is more or less open. Unison, MLDonkey and Hevea can be considered real world applications written in Objective Caml. The C library interface is comprehensive and not overly complicated. The startup time for small programs is very fast and still harmless for larger pieces of code.

The libraries accompanying Objective Caml suggest that it is suitable for UNIX system programming. Threads are supported, however inside a process only one thread may execute Objective Caml code (similar to the interpreter lock in Python). Objective Caml has a safe core, in which most applications can be developed. A source-level debugger is available, although it works only on bytecode and is a bit unconventional to use (for instance, it supports time-travelling). Garbage collection is mandatory and cannot be disabled.

Nevertheless, one doubt remains: can a functional language compete in terms of speed? Or will the time-critical parts again have to be implemented in C or C++? In this case, it would seem to be better to glue the C/C++ components together with a scripting language like Python, which is more common among developers.

The answer in advance: Objective Caml produces surprisingly fast code without requiring the programmer to do obscure stuff. This is even more astonishing if you keep in mind that according to common belief several obstacles stand against this:

  • The runtime environment uses a garbage collector, i.e. memory management is mostly automatized.
  • Objects are "tagged" at runtime. The static type information available at compile time therefore gets partially lost. This can result in a rather unnecessary overhead for managing the tags.
  • The whole compiler is much smaller than the Tree-SSA optimizer in GCC alone! Therefore, many steps of optimization cannot be included. Furthermore, the compile process itself runs pretty fast (especially when compared to MLton), so there is simply not much time for extensive algorithms.

These obstacles are apparently not as grave for actual Objective Caml code as previously thought. The tagging problem is not as bad as in languages like Lisp, since for example an arithmetic addition does not have to check the tags at runtime because the required operation can be determined at compile time. Method calls play a smaller role than in Java because of the existence of closures. Also, the richer type system prevents to create a class for every minor detail.

The last open point is garbage collection. Objective Caml uses a pretty sophisticated collector using two generations. This means that allocating small short-lived objects is very cheep (cf. Brian Goetz, Urban performance legends, revisited - Allocation is faster than you think, and getting faster, September 2005 for a similar view). According to first tests, memory-intensive Objective Caml programs spend fortunately little time inside the garbage collector.

Altogether Objective Caml is a promising project. Since the list of supported platforms is pretty large, Objective Caml is a valuable alternative, especially if you want to get around using C++.

Got a question on Objective Caml? Post it as a comment!

Objective Caml
License:Q Public License (compiler), LGPL (libraries)
Distributions: [?]■ Debian stable■ Debian unstable
■ Fedora■ Mandriva
■ Suse■ Ubuntu


  • Advanced multi-paradigm programming language
  • Mature programming environment
  • Complete toolchain
  • Relatively small development community
  • Lack of full threading support

Copyright 2006–2008 OS Reviews. This document is available under the terms of the GNU Free Documentation License. See the licensing terms for further details.

  • Advertisement