From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 2D8F47EE25 for ; Tue, 12 Nov 2013 04:44:46 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nanaki@gmail.com) identity=pra; client-ip=209.85.128.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nanaki@gmail.com"; x-sender="nanaki@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of nanaki@gmail.com designates 209.85.128.175 as permitted sender) identity=mailfrom; client-ip=209.85.128.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nanaki@gmail.com"; x-sender="nanaki@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ve0-f175.google.com) identity=helo; client-ip=209.85.128.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nanaki@gmail.com"; x-sender="postmaster@mail-ve0-f175.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkEAMqjgVLRVYCvlGdsb2JhbABTBoM/U4J1qUmKFohGgTsIFg4BAQEBBwsLCRIqgiUBAQQBIwQZARsSCwEDAQcEBgMCCwYEAQEOGgMCAiIBEQEFAQoBCQgZEodcAQMJBg2QLI9ajARTgwmEUQoZJwMKZIhLAQUMjiGBKQQHBoJlgUUDiUKJUIR9gS+ObxgphHIb X-IPAS-Result: AjkEAMqjgVLRVYCvlGdsb2JhbABTBoM/U4J1qUmKFohGgTsIFg4BAQEBBwsLCRIqgiUBAQQBIwQZARsSCwEDAQcEBgMCCwYEAQEOGgMCAiIBEQEFAQoBCQgZEodcAQMJBg2QLI9ajARTgwmEUQoZJwMKZIhLAQUMjiGBKQQHBoJlgUUDiUKJUIR9gS+ObxgphHIb X-IronPort-AV: E=Sophos;i="4.93,682,1378850400"; d="scan'208";a="35082730" Received: from mail-ve0-f175.google.com ([209.85.128.175]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Nov 2013 04:44:45 +0100 Received: by mail-ve0-f175.google.com with SMTP id jw12so3281925veb.20 for ; Mon, 11 Nov 2013 19:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6KHMI62HAonZTIfHPhN9b8DV7HCYDiSetU80YsIiiwU=; b=jCzaONT/oJIxPinonK8HkmttPfkpCvqxqZ8tJQK3/RO6d/fcdutsBlMPaH/ooyRg/R hElzN90o4lTQMKqBt6ETXNpQKUCfb53+VcQSSQWZ5EQmsJMHpZrgSeEKbQRBUqb11dzX tXfBntGnjxqMTKXk1NdDYgwdP0LPV+jubpPniewdseIbKtHZwALqwzlI1c7q7DsmIo5V LDLWjYUYMRl5afxC0sz2hXpAYpYhBA4lOo4KdGVC99K71UaJgZds9dkiMH4+K8fvTef5 tTypIEMpSrl6KCJXE3Fe8EOPXtP0n28P+HDMVvyyAOgbef5/VQ2EXLxwgr/8D1HsX5lM 2l2g== MIME-Version: 1.0 X-Received: by 10.58.54.69 with SMTP id h5mr794117vep.25.1384227883723; Mon, 11 Nov 2013 19:44:43 -0800 (PST) Received: by 10.58.220.135 with HTTP; Mon, 11 Nov 2013 19:44:43 -0800 (PST) In-Reply-To: <012101cedc76$1665b920$43312b60$@ffconsultancy.com> References: <010801cedc66$0425bcc0$0c713640$@ffconsultancy.com> <14f25a35d63f2b6ce6185d86dc66d2bd@whitequark.org> <012101cedc76$1665b920$43312b60$@ffconsultancy.com> Date: Mon, 11 Nov 2013 19:44:43 -0800 Message-ID: From: Jeff Meister To: jon@ffconsultancy.com Cc: Peter Zotov , Caml List Content-Type: multipart/alternative; boundary=089e013cbbb04c311304eaf2abea Subject: Re: [Caml-list] LLVM OCaml bindings --089e013cbbb04c311304eaf2abea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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? On Fri, Nov 8, 2013 at 3:31 AM, Jon Harrop wrote: > > I'm not going to change APIs in any way which needs nontrivial, > significant fixes to clients, there's simply no need. > > Ok, great. > > Jeff Meister was talking about writing more type safe bindings. I think > that would be fine as long as it wraps the existing less-safe bindings so > people can continue to use them. I tried using LLVM from Haskell and had a > lot of problems because they'd used every trick in the book to write the > most type safe possible bindings and it makes it much harder to learn and > use. I'd personally much rather see more complete bindings... > > BTW, what are your thoughts on MSJIT? I just started reading about it and > it seems very underwhelming. Sounds like they're struggling to refactor > their C++ code so they're reinventing things but not doing it significant= ly > better. So I don't think I'll be rushing to switch to MSJIT unless they > actually deprecate the old JIT. > > Cheers, > Jon. > > -----Original Message----- > From: Peter Zotov [mailto:whitequark@whitequark.org] > Sent: 08 November 2013 10:19 > To: jon@ffconsultancy.com > Cc: caml-list@inria.fr > Subject: RE: [Caml-list] LLVM OCaml bindings > > Jon Harrop =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 08.11.2013 13:36: > > I just wanted to check: you're not breaking the existing bindings, > > right? > > Sorry, realized the previous letter was phrased ambiguously. > I'm asking because I do want to break existing bindings. The changes would > mainly touch two areas: > 1) Memory management. I want to get rid of most or all of dispose > functions and allow to use OCaml's GC. > 2) Llvm_target interface is very outdated and it could be updated to > integrate much better with the TargetMachine interface. > > There are also two or three Llvm functions which need minor changes. > > I'm not going to change APIs in any way which needs nontrivial, > significant fixes to clients, there's simply no need. > > -- > 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 > --089e013cbbb04c311304eaf2abea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jon and Peter,

My vers= ion of the bindings was constructed to directly wrap the underlying externa= ls and replace the existing interface, but there's no reason it couldn&= #39;t be changed to wrap the existing unsafe bindings instead, and leave th= e 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 thi= nk I've been very tricky with mine. My goal was simply to take the exis= ting bindings over the unsafe C interface and re-establish the type safety = that exists in LLVM's C++ code by reintroducing the inheritance hierarc= hy on the OCaml side. I need a couple unusual patterns for this, but otherw= ise it's still the low-level C API, you just don't have everything = represented as a top-level function anymore. For example, "val functio= n_call_conv : llvalue -> int" becomes "method call_conv : int&= quot; 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 i= magine 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 inh= eritance hierarchies into opaque pointers like llvalue and lltype, since th= at's all C lets you do. But that's just not acceptable to me in OCa= ml, where I have the tools to correct the situation. If I have to give up s= tatic 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 o= nes, it would be great to add these additional functions. But I'm curio= us, 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 upst= ream themselves?


On Fri,= Nov 8, 2013 at 3:31 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
> I'm not going to = change APIs in any way which needs nontrivial, significant fixes to clients= , there's simply no need.

Ok, great.

Jeff Meister was talking about writing more type safe bindings. I think tha= t would be fine as long as it wraps the existing less-safe bindings so peop= le can continue to use them. I tried using LLVM from Haskell and had a lot = of problems because they'd used every trick in the book to write the mo= st type safe possible bindings and it makes it much harder to learn and use= . I'd personally much rather see more complete bindings...

BTW, what are your thoughts on MSJIT? I just started reading about it and i= t seems very underwhelming. Sounds like they're struggling to refactor = their C++ code so they're reinventing things but not doing it significa= ntly better. So I don't think I'll be rushing to switch to MSJIT un= less they actually deprecate the old JIT.

Cheers,
Jon.

-----Original Message-----
From: Peter Zotov [mailto:whit= equark@whitequark.org]
Sent: 08 November 2013 10:19
To: jon@ffconsultancy.com
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] LLVM OCaml bindings

Jon Harrop =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 08.11.2013 13:36:
> I just wanted to check: you're not breaking the existing bindings,=
> right?

Sorry, realized the previous letter was phrased ambiguously.
I'm asking because I do want to break existing bindings. The changes wo= uld mainly touch two areas:
1) Memory management. I want to get rid of most or all of dispose functions= and allow to use OCaml's GC.
2) Llvm_target interface is very outdated and it could be updated to integr= ate much better with the TargetMachine interface.

There are also two or three Llvm functions which need minor changes.

I'm not going to change APIs in any way which needs nontrivial, signifi= cant fixes to clients, there's simply no need.

--
=C2=A0 =C2=A0WBR, Peter Zotov.


--
Caml-list mailing list. =C2=A0Subscription management and archives:
ht= tps://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
--089e013cbbb04c311304eaf2abea--