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
>