Lambda the Ultimate

Made the appropriate correction.

First, I suggest that you read this, and follow the links from it. In particular, follow the link in the post immediately following mine, to "Independently Extensible Solutions to the Expression Problem," which does the best job I've seen so far of describing the problem space and explaining why the currently popular statically-typed languages have difficulty addressing it. It then shows why Scala doesn't suffer from these problems. "Code Reuse Through Polymorphic Variants" and "On the (Un)reality of Virtual Types" both do an excellent job of explaining why O'Caml doesn't suffer from the difficulties, either. In the post that I link to above, I basically copy straight out of "Code Reuse Through Polymorphic Variants" the solution to writing an open evaluator for a language of variables, lambda expressions, addition, and multiplication, where each mini-language (evaluator for the "var expression" type, evaluator for the "lambda expression" type, evaluator for the "addition and multiplication expression types") is developed independently of the others, but they compose successfully and without contortions of any kind. "On the (un)reality of Virtual Types" in particular makes the strong point that correct typing of binary methods, open self types, and structural typing are sufficient to handle the "expression problem" without resorting to higher-order polymorphism or any of the other heavier-weight approaches to the problem.

At this point I have to confess that sometimes in my static typing advocacy I forget that I'm really advocating O'Caml: very few statically typed languages, even really good ones like Haskell, get as much right as O'Caml does (although GHC 6.5 and all the STM stuff is extremely important). O'Caml's also not pure: it has mutation, for loops, and so on, so it's a lot easier to be an O'Caml convert than a Haskell convert (IMHO). But if all you've experienced of statically-typed languages is even, say, SML/NJ or Haskell 98 vs. GHC, O'Caml, or Scala, no doubt I seem like a madman.

All things considered, I think OCaml is one of the best languages out there. Great tools and performance, good type system with inference, support for OOP (for when its really the right tool for the job), structural subtyping, etc. It's great for converting both dynamic typing advocates and OOP advocates.

Haskell on the other hand is the language most interesting research stems from (although OCaml has FlowCaml and TyPiCal, etc too), and future languages can learn a lot from it. I think these future languages should be impure, but with a purely functional subset you can restrict yourself to: making use of techniques learnt from Haskell. The type system is the other core area that can be improved.

Oh, I get it. Thanks for the link.

At this point I have to confess that sometimes in my static typing advocacy I forget that I'm really advocating O'Caml: very few statically typed languages, even really good ones like Haskell, get as much right as O'Caml does.

Every time I get bitten by laziness in Haskell, I start leaning towards learning O'Caml. But that feeling goes away when I think about leaving things like multi-parameter type classes behind. So what snazzy new features do I get in O'Caml to help assuage my pain? Apparently there's a nifty module system. Any others? Is there an advocacy site or concise guide available which shows off the bells and whistles of O'Caml?

And can anyone recommend a good dead tree book for learning O'Caml? In the future, there's Practical OCaml. Any others worthy of mention? Or should I just bite the bullet and try printing and binding something like Developing Applications With Objective Caml?

Please see Oleg Kiselyov's Applicative Translucent Functors in Haskell. Here I quote the "upshot of the translation" section at the end:

The upshot of the translation:

ML signatures correspond to Haskell type classes, and their
implementations to the instances

Abstract types in ML correspond to either uninstantiated or
explicitly quantified type variables in Haskell

Type sharing is expressed via type variable name sharing

Functor (signatures or structures) correspond to Haskell (class
declarations or instances) with type class constraints

The argument of functors is expressed via types, with additional labels
when needed for finer differentiation

Functor applications are done by instance selection based on types
at hand plus the additional labels

OCaml signature attribution operation -- casting the module or
the result of the functor into a desired signature and hiding
the extras -- sometimes involves additional tagging/untagging tricks
(cf. SetESet). This tagging, done via newtype, is syntactic only and
has no run-time effect.

Hiding of information (`sealing', in ML-speak) is done by
existential quantification. To gain applicativity, we quantify over
a higher-ranked type variable (Skolem function proper).

One way to interpret this is that O'Caml modules are more straightforward to use than type classes in some sophisticated cases. :-) Another is that you don't "lose" type classes, but the downside is that you do have to actually understand O'Caml's module language (vs. treating it as just a tool supporting separate compilation, which is how I treated it for about the first two years of my exposure to it).

With respect to dead tree books, I quite like O'Caml for Scientists.

One thing I do believe is lost is the ability for the compiler to figure out the correct module/structure? I do think there're more good things to come of these isomorphisms just yet - the ML approach does have certain freedoms that typeclasses don't (more than one instance for the same tuple of types, for example)

Don't know if it helps, but Andreas responded to a question I had on the comparison between ML Functors and Haskell Type Classes.

Good point!

I'm not quite understanding what that means. Do you always have to fully qualify the functor(?)? Or, here's a slightly different way of asking if modules can subsume type classes. Can you more-or-less translate things like Number-parameterized types, etc. into O'Caml?

As far as I can tell, "Number-parameterized types" just require the ability to encode numbers as existential types. "Existential types" in members of the ML family are just types that are left abstract in the module's signature. See the end of this post on the O'Caml mailing list for an example of using "phantom types" (which must be existential, hence abstract, hence expressed via a module signature) to provide statically-dimensioned arrays.

Actually, AFAIK, Haskell's type classes (with a number of extensions) allow you to specify rather arbitrary relations on types. No such mechanism exists in Standard ML or, AFAIK, in O'Caml for that matter. Intuitively speaking, I find that "evaluation" at the type level is "parametric" in ML and "non-parametric" in Haskell.

As far as I can tell, "Number-parameterized types" just require the ability to encode numbers as existential types. "Existential types" in members of the ML family are just types that are left abstract in the module's signature. See the end of this post on the O'Caml mailing list for an example of using "phantom types" (which must be existential, hence abstract, hence expressed via a module signature) to provide statically-dimensions arrays.

There have been rumblings in the ML community about type classes as a usage pattern of modules. The only thing I've come across so far is a draft of Modular Type Classes by Dreyer, Harper, Chakravarty and Keller.

I'd been about to link to that. I'd been toying around a bit on my own with a different but pretty obvious approach - I should bash up some code sometime.

I contributed this thread a couple of weeks ago and reading it back I realized I made links to the home pages of two of the authors while omitting the third. So I corrected that.
When contributing this post I was not an editor yet, so I had no rights to put it anywhere else. Now that I have the proper authorities I will be careful putting my contributions in the appropriate category.
Is there any way to make small corrections and not have the item pop up at the top of the list?

Sorry about that, I didn't notice this was an old thread (I usally do...). Changes appear at the top of the tracker: that's the whole point of the tracker (the "recent posts" page) and it's a Good Thing, otherwise changes will never be noticed.

Anyway, I can promote this thread to the home page if you want.

Is there any way to make small corrections and not have the item pop up at the top of the list?

No, not as far as I know.