[LLVMdev] Python bindings?

[Gordon Henriksen]

On Mar 28, 2008, at 03:57, Erick Tryzelaar wrote:

> On Fri, Mar 28, 2008 at 12:00 AM, Mahadevan R  
> <mdevan.foobar at gmail.com> wrote:
>> 1)
>> Are the C bindings complete? That is, is there some part of the C++  
>> API that is not exposed by the C API?
>
> Nope, there's still a lot that's not done. Patches are always  
> welcome :) We've got enough in subversion to implement the  
> Kaleidoscope tutorial though.

I like to think we're binding with a goal. :) So when a need is  
satisfied, it's “done” for that need. As Erick well knows, I'm happy  
to accept patches to extend the bindings into any areas of interest.

Very much of LLVM's functionality is either truly or essentially  
private, so varying definitions of “everything” are either pointless  
or unsatisfiable.

>> 2)
>> Do the Ocaml/Haskell bindings follow that language's naming  
>> conventions?
>> Or LLVM's? For e.g., in Python method names are usually like_this. So
>> which of these are preferred:
>>
>>  Builder.set_insert_point()
>>
>> or
>>
>>  Builder.SetInsertPoint()
>
> I can't speak for the haskell bindings, but the ocaml bindings do  
> not. We use the lowercase/underscore format traditionally used in  
> ocaml projects.

Tradition, schmadition; capitalization is part of the Objective Caml  
syntax. :P

> We don't need to bind all of the helper functions and methods so the  
> api can be kept a little smaller. They also might be named  
> differently and the semantics can be changed. For instance, the  
> function "createPromoteMemoryToRegisterPass" creates a Pass object  
> that we can add to a PassManager, but in ocaml we have  
> "add_memory_to_register_promotion" which takes a PassManager as an  
> argument and adds it inside the binding. This makes memory  
> management a bit simpler.

Something that the C bindings provide that I think is actually  
valuable is a considerably simplified memory ownership model,  
particularly for the IR. The C++ side doesn't participate in GC, and  
it is therefore not knowable whether an object needs to be disposed of  
or not when the managed handle to it become garbage.

Since the C bindings don't expose the features that allow for the  
creation of detached IR objects, 'delete Module' is guaranteed to to  
clean up any IR objects properly. Such detached objects are not  
especially useful to compiler front-ends. The bulk of memory  
management simply disappears from both bindings and client code using  
this model. In particular, bindings don't need to implement finalizers.

— Gordon