Well the use of C++ instead of OCaml allowed us a certain number of things :
- Most notably reading OCaml's header files, and hence using the correct, macro declared data types in LLVM code generation. This could have been done with an hybrid of C and OCaml, but was much simpler in OCaml.
- Also using OCaml runtime to read the bytecode. This could have been done in OCaml, but would have been more tedious.
Also you have to consider this project isn't treating an AST per se (the thing at which ML languages excels, by the use of sum types) but a bytecode array, which is flat in structure. We put back some structure in it, but it is predictable and not as complex as an AST.
I am all for using the right tool for the job, and I like C++ (except for a few things like lack of modules. :) ).
For an outsider which loves ML languages, OCaml still looks it could have been a better solution.
This is like doing bootstrap compilers, sometimes the efforts of such tasks lead to improvements on the language eco-system.
Then again, this is about using what you thought was the best tool at hand, so don't take it badly for my negative comment and good luck for the project.
This project has more fundamental issues in my opinion if you want to consider it as a real replacement for ocamlopt, as i explained here http://news.ycombinator.com/item?id=4798320. It is not, just a replacement for OCaml's interpreter, and as such it is a very simple project and will probably remains so. I don't plan to make it evolve beyond bug-fixing and maintaining it.
As such, if i had to re-code it in another language, it would be in C, to make it integrable into OCaml's runtime easily. Probably not OCaml, because its expressive power is not needed.
If i had to start from scratch, i would do an LLVM backend for the ocamlopt compiler. And i would do it in OCaml of course :)
Specially taking into consideration how much better OCaml is suited for compiler development and the existence of LLVM bindings for OCaml.