Hi Jon and Peter,
My version of the bindings was constructed to directly wrap the underlying externals and replace the existing interface, but there's no reason it couldn't be changed to wrap the existing unsafe bindings instead, and leave the unsafe interface exposed as well. I'm working on updating my code to the latest version of LLVM, and I can incorporate that change.
I haven't looked at the Haskell bindings, but I don't think I've been very tricky with mine. My goal was simply to take the existing bindings over the unsafe C interface and re-establish the type safety that exists in LLVM's C++ code by reintroducing the inheritance hierarchy on the OCaml side. I need a couple unusual patterns for this, but otherwise it's still the low-level C API, you just don't have everything represented as a top-level function anymore. For example, "val function_call_conv : llvalue -> int" becomes "method call_conv : int" inside class Function.c. Translating code from the existing bindings to my version would be straightforward and mechanical.
Aside from compatibility with existing code though, I can't imagine why any OCaml programmer would want to use a type-unsafe version of the LLVM bindings. The C API gets a pass for flattening LLVM's deep inheritance hierarchies into opaque pointers like llvalue and lltype, since that's all C lets you do. But that's just not acceptable to me in OCaml, where I have the tools to correct the situation. If I have to give up static type safety to work with LLVM in OCaml, then I might as well not use OCaml on that project.
If the Haskell bindings expose more capabilities than the OCaml ones, it would be great to add these additional functions. But I'm curious, how are they getting additional functions? Can Haskell bind directly to C++ without going through C? Or have the Haskell folks made major changes to the LLVM C API? And if so, why wouldn't they push those changes upstream themselves?