Monads in OCaml

So, there. Someone who has never programmed in Haskell probably never encountered the idea of monads -- unless it is someone who works in semantics and has read Moggi's works; but I digress. An interesting way to tackle the idea of monads is to look at them outside of Haskell, and see how it works in other languages. Often, other languages don't have what it takes to express the concept of a monad in its full generality, but specific monads can always be implemented. In this regard, there's this page by oleg, and there's this other one about monads in Ruby. I remember seeing somewhere a page that compiled monad implementations in various languages, but I can't seem to find it now.

Anyhow, Brian Hurt has written a very nice tutorial about monads in OCaml. It uses the module system and functors (see comments) to define a reasonably general monad concept in OCaml. It's a good read.

Towards Global Domination

If you haven't yet seen them or heard about them somewhere else, it seems that the videos of Simon Peyton-Jones' talks at OSCON are quite a hit.

And people still look at me funny when I say that functional programming is going to take over the world.

Battle of the OCaml plugins for Eclipse

A new OCaml plugin for Eclipse, called OcaIDE, has just been announced. Apparently, it has been under development for a long time. It seems to be quite complete in features, although I didn't try it yet. The question is that this is the third OCaml plugin being developed currently; there's ODT, about which I talked in a earlier post, and another one being developed as one of the OCaml projects in the Google Summer of Code. The competition is good in some ways, but on the other hand the resulting fragmentation can be a problem to a small community like that of OCaml. It would be best if the teams managed to combine their efforts in some way. Let's see how this plays out.

Speaking of collaboration, there's mention on OcaIDE's site about a free-software license, but the source code doesn't seem to be available.

UPDATE: As someone pointed in the comments, the source is available together with the plugin. See here.

Review: Practical OCaml

Executive summary: this is not Practical Common Lisp for OCaml. It's ambitious but disappointing. However, it's not so bad as it seems at first sight.

OCaml is a sexy language that combines the expressiveness and terseness of scripting languages with the static type checking and performance of languages like C++ and Java. A book may be a good investment to learn a new language, and this is one of the few books available on the language. How does it fare?

This book has received very harsh criticism overall, and it mostly deserves it; it is somewhat of a mess. But it is not uniformly bad: some chapters are very bad, others are acceptable or interesting, depending on your background. The problem seems to be that the worst chapters come first; although it shows signs of bad editing throughout, the first few chapters are especially bad. And I mean really bad: bad text, bad editing, bad examples, lots of senseless repetition, conceptual errors, using language features not yet introduced (and that go unexplained), the list goes on. Later chapters are considerably less irritating.

Clearly inspired by Peter Seibel's terrific book Practical Common Lisp, the chapters on this one are divided in two types: the ones that explain the language, and the "Practical" ones, containing extended examples. This is a great idea, and even badly executed as it may be in Practical OCaml, it still results in interesting chapters. Actually, the Practical chapters are overall better than the language ones; from them, a reader can get a real sense of using OCaml in simple but realistic projects, integrating many different libraries and tools, some of them not contained in the standard OCaml distribution. Still, the code in these chapters can be criticized for their style. For one thing, I think the author uses classes and other OO features much more often than they appear on real OCaml programs. Nonetheless, an experienced programmer could get a lot of interesting pointers from these chapters, by knowing what to salvage and what not to replicate from the code.

But the rest of the book, the OCaml chapters, are in really bad shape. They don't explain things very well, and fails miserably at the more difficult aspects of the language. The chapter on modules and functors is so bad as to be almost useless; don't try to learn about functors from this book. Camlp4, the nifty tool for metaprogramming and extension, is other subject with a bad treatment. The chapter on Threads could be improved a lot, but it still gives a general idea of how multithreaded programming in OCaml is. Again, for experienced developers, it should provide pointers for further study.

If experienced developers can get something from this book, novice ones should stay away from it. Not only is the text confusing, but there are a lot of glaring conceptual errors. Maybe some errors are to be expected from a trade book, from an author that is not an academic, but there
are things that are completely confusing. For example, this is the definition of type (page 24): "A type is a thing (or a collection of things) or value." And there is a lot more like this, unfortunately.

Overall, it has interesting parts, but surely not enough to make worth the full cover price. For experienced programmers and people already familiar with other typed functional programming languages (Haskell, F#, SML, etc), the book could serve as an initial guide for OCaml programming, but there are better alternatives around.

F# Performance

There's a comparison of F# versus IronPython in Robert Pickering's blog. The results show that F# has roughly the same level of conciseness and terseness of Python, while being close in performance to C#. This is a .NET-based comparison, but it would be interesting to compare F# with CPython to see where it stands. If we are to believe this discussion on the python-dev mailing list, it seems that IronPython's performance must be comparable to CPython's, so there we have it: .NET or not, F# strikes an interesting balance in the expressiveness versus performance trade-offs.

This is also my personal experience with OCaml: performance roughly comparable to C/C++, but expressive and concise like scripting languages. It is this interesting position in the expressiveness x performance curve that makes both F# and OCaml very worthwhile languages to learn and use today.

The EOPL in F# wiki

I've started moving the content for the "EOPL in F#" translation to a wiki. Unfortunately, I have also been insanely busy as of late, so there's only the beginning there. However, as I'll have more free time from now on, I intend to catch up with what's already here and then start posting more sections that I already translated. I also noticed I never posted some parts because I forgot to, so it will be added to the wiki as well. Anyway, here is the link:

EOPL in F# Wiki

OCaml with Eclipse

The primary editor on which to write OCaml code has always been Emacs. This tends to be a problem for users on Windows, that mostly aren't familiar with the editor. And of course there are many people that use unix platforms and don't like Emacs.

A good alternative is Eclipse, which has very good plugins for Java programming, and can be extended to handle other languages. ODT, a plugin for OCaml development in Eclipse, is being actively developed by Emmanuel Dieul. Actually there's another plugin in development by someone under the Google Summer of Code, and we hope they can integrate both efforts to get a better plugin in the end.

Anyway, ODT looks interesting right now, and it's been evolving quite fast. Eclipse is quite a memory hog, but if you already use it or are willing to pay the requirements, it can provide a modern IDE for OCaml under Windows or unix, and a good alternative for Emacs. Let's hope ODT keeps improving.