Lambda the Ultimate

A story taking the three most common uses of C++ templates and contrasting with features of other language that accomplish the same. He mentions ML's type inferencing, functors, and Lisp macros specifically.

Putting aside the obvious fact that one of the main reasons for using a high-level PL is writing a little source that translates into a lot of code, I would like to address this claim specifically.

I'm reminded of one of the initial arguments against C++, even before templates, that it generates code that is less efficient than C. When examined in detail, often these claims were made by newbie C++ programmers that wrote code in a way that resulted in lots of unnamed temporary variables (C++ can automatically and implicitly create unnamed variables as temporary value containers within an expression). These unnamed temporaries introduced overhead both in their creation and destruction.

It could usually be shown that many of these temporaries was superfluous and could be avoided through proper application of C++ coding techniques (yes, you do need to know C++ well in order to fully grasp the implications of what you are doing).

IMO the same is true for templates. Yes, you can write templates in such a way that code becomes bloated. But, using standard C++ features such as inheritance and partial template specialization, it's quit possible to write code in a way that doesn't bloat it. In fact, when combined with inlining and an optimizing compiler, the resulting code can often be more efficient and less bloated.

Oh, and yes, I did like the article. I think it would be useful, as Ehud has pointed out, to contrast C++ to the implementation of generics in a language that is closer to C++ than ML or Lisp, say Ada, Java or C#.

And Patrick is probably finding this whole discussion rather amusing.

In conclusion: I like OCaml much better than C++. Basically, the only C++ feature I miss when writing OCaml code is templates. Most uses of templates could be replaced by ML generic polymorphism or ML functors, but the result would likely be significantly less efficient with many (perhaps all) ML compilers, and would in some cases be far more verbose. I would love to have a language in the ML family that supported C++-style templates (but this would be difficult, since the more interesting features of templates are difficult to combine with type inference).

As far as comparing C++ templates to Lisp/Scheme macros, I would say that they're not really comparable; there are many things which you can do with one but not the other. The main thing you can do with templates that you can't do with any other macro-style system I know of is compile-time dispatch based on the compile-time types of the chunks of program being manipulated. Lisp can't really do this, since Lisp doesn't really have a compile-time type system. (Maybe you could add a type inference system into your macro expansion, but the result would be clumsy and fragile.) It's difficult in ML (or any other language that uses type inference) as well, since you would have to mix macro expansion and type inference somehow.

I don't think MacroML (thanks for the pointer, by the way) lets you dispatch on types. Neither does Template Haskell, which I believe is essentially a Lisp-style macro system for Haskell.

GCaml currently works with an older version of the Ocaml toplevel, but will be updated. (see this message.)

I note that the implementation described in the thesis does run-time type dispatch. I would prefer an implementation which did compile-time specialization. (An experiment done by Mark Jones, in the context of Haskell type classes, showed that compile-time specialization both increased speed and reduced total code size. This would surely depend on programming style, etc.; but it's an interesting result.)