On Tue, Nov 5, 2013 at 11:19 PM, Peter Zotov <whitequark@whitequark.org> wrote:

Jeff Meister ĐÉÓÁĚ 06.11.2013 01:00:

I can call const_int to get an llvalue representing an integer, then
pass this llvalue as the first argument to build_call, which expects a
function. Since both have type llvalue, the OCaml type checker will
not complain, but a segfault or other undefined behavior will likely
result at runtime.

As mentioned elsewhere, it's defined in Asserts build. Personally,
I'm going to ship my compiler with LLVM built in Release+Asserts mode.

Sure, but those are runtime assertions, not compile time type errors. In my opinion, if the correct types can be expressed in OCaml, we should use them. Collapsing LLVM's complex subtype hierarchies into types like llvalue and lltype is not acceptable to me as an OCaml programmer. I might as well program in C.

What I did to fix this was reintroduce the inheritance hierarchy
present in the C++ code. Using some module system tricks to make
OCaml's structural subtyping act like nominal subtyping, I refactored
everything into classes. In my version, const_int would return a
ConstInt.t, which is a subtype of Value.t, but not compatible with the
Function.t required by build_call.

One thing to consider is that the C++ API does not use subtyping for
this kind of safety, either. Consider the prototype of
IRBuilder::CreateCall:
CallInst *CreateCall (Value *Callee, ArrayRef< Value * > Args, const Twine &Name="")

This means that there is no guarantee you can convert the API to use
the subtyping safety measure you devised. Indeed, there are several
functions which do not have an equivalent type in hierarchy.
Llvm.set_volatile expects a [load] or [store], where Llvm.set_alignment
expects a [load], [store] or a global value, and Llvm.set_atomic_ordering
expects a [load], [store], [atomicrmw], [fence], or [cmpxchg].
LLVM itself represents this by trying to explicitly cast the instruction
to each supported one, and then calling the corresponding method.

Interestingly, this kind of relationship can be expressed better by OCaml's
structural OO system than C++'s nominative one. I think that a project
to wrap either LLVM's C or C++ API into OCaml's classes and objects may
be a good solution to at least part of the problem. I don't have time
to develop this myself, though.

That's a very interesting point! In my implementation, I simply duplicated the C++ method types, so if a parameter had type Value in C++, the same was reflected in the OCaml interface, even if the actual type is more complex as you described. My goal was simply to get the OCaml bindings on par with the C++ types to prevent undefined behavior (or runtime assertion failures) from mistaken casts that can easily be detected statically in OCaml. If we could use the OCaml type system to go even further than C++, that would be excellent!

I will try to find my code and put it up on GitHub if it would be useful to you.

I would be interested to look into it, but I probably will not integrate
it into the bindings.

--
š WBR, Peter Zotov.

--
Caml-list mailing list. šSubscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs