From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 697D97EE25 for ; Thu, 14 Nov 2013 20:29:45 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of nanaki@gmail.com) identity=pra; client-ip=209.85.212.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nanaki@gmail.com"; x-sender="nanaki@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of nanaki@gmail.com designates 209.85.212.47 as permitted sender) identity=mailfrom; client-ip=209.85.212.47; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vb0-f47.google.com) identity=helo; client-ip=209.85.212.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nanaki@gmail.com"; x-sender="postmaster@mail-vb0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcDABYkhVLRVdQvlGdsb2JhbABbgz9HDKxDihGIRYEZCBYOAQEBAQcLCwkSKoIlAQEEAUABGxILAQMBCwYFCwMKDQwBARMhAQERAQUBChIGExKHXAEDCQYNogOMV4MJhFgKGScDCmSIVQEFDIxhgm4EByMEhAoDiUKMY4FrgS+LJYNMGCmCaIIMGw X-IPAS-Result: AvcDABYkhVLRVdQvlGdsb2JhbABbgz9HDKxDihGIRYEZCBYOAQEBAQcLCwkSKoIlAQEEAUABGxILAQMBCwYFCwMKDQwBARMhAQERAQUBChIGExKHXAEDCQYNogOMV4MJhFgKGScDCmSIVQEFDIxhgm4EByMEhAoDiUKMY4FrgS+LJYNMGCmCaIIMGw X-IronPort-AV: E=Sophos;i="4.93,701,1378850400"; d="scan'208";a="42811743" Received: from mail-vb0-f47.google.com ([209.85.212.47]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Nov 2013 20:29:25 +0100 Received: by mail-vb0-f47.google.com with SMTP id g10so2070763vbg.20 for ; Thu, 14 Nov 2013 11:29:24 -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=AphgML6qI0DSAv6qSWC4Wx1bqWI6Ge9wLWlUNEMJP08=; b=fRyYOTmUCFtmCMYErwmtpbUVq7Megs4BGogoMgQ1mG3iFPfUEJm+zKUs+J1rTQoylX uGdqfDD0YpFVrlGsayjyHYfctCytlBvOypMklTC4K8H9bOwu/Skvf0Gw3ZCHKSt2StiO 8JdaCrJ4o6CBuaVzvh7lZjzw3fqKfHDbZdTT3R3lOnsO04w3PIpYagonTr3uXVOXCO2x ftjOVPTKeCV6boc+xaOmydFeDgbpGfE/awjsAVK0v28fcZNx6wlz4hecyKxjX606L3yH 7+g0SEPtx6c0YJA7qpKu/iugaDTmciFyQ1yJ8sEKfY0IpAjtZP6bu2UyUYuDjMe9eyKo A5Cg== MIME-Version: 1.0 X-Received: by 10.52.106.201 with SMTP id gw9mr495083vdb.49.1384457364584; Thu, 14 Nov 2013 11:29:24 -0800 (PST) Received: by 10.58.220.135 with HTTP; Thu, 14 Nov 2013 11:29:24 -0800 (PST) In-Reply-To: <5284F4FF.2000900@gmail.com> References: <010801cedc66$0425bcc0$0c713640$@ffconsultancy.com> <14f25a35d63f2b6ce6185d86dc66d2bd@whitequark.org> <012101cedc76$1665b920$43312b60$@ffconsultancy.com> <01f601cee0a2$aae0b520$00a21f60$@ffconsultancy.com> <5284F4FF.2000900@gmail.com> Date: Thu, 14 Nov 2013 11:29:24 -0800 Message-ID: From: Jeff Meister To: Hongbo Zhang Cc: Jon Harrop , Caml List Content-Type: multipart/alternative; boundary=bcaec5485a986c458304eb281952 Subject: Re: [Caml-list] LLVM OCaml bindings --bcaec5485a986c458304eb281952 Content-Type: text/plain; charset=ISO-8859-1 There is basically no extra complexity, just refactoring. The only difference is that, for example, setting the initializer for a GlobalVariable.c statically requires a Constant.c, not just any llvalue as allowed by the existing bindings. I don't see this as additional complexity, because you have to know the real types anyway to work with the current bindings. I'm simply making them explicit in the interface. There is unfortunately the annoyance of frequent upcasts: to past your Constant.c x to a function that expects a Value.c, you must write (x :> Value.c). But that limitation of the OCaml language can be removed, and it already has been in the implicit_subtyping branch. I would love to see those changes integrated into mainline OCaml, or at least updated to work with the latest release! :) You guys are right that I was too sweeping with my statement about type safety... the other features you mentioned are great reasons to prefer OCaml, and they're important to me too. What I should have said was, I don't want to have to sacrifice type safety of the bindings so I can work in OCaml, especially when I see no fundamental reason why that sacrifice is necessary. Frankly I was very surprised when I first discovered that the bindings are so inadequate in this respect, and that no one had done anything about it. Maybe that's because no one cares, but I doubt it. It may not be the most important thing, but I see it as free help from OCaml's type and module systems, and I'll take that help, especially when working with such a large and complex project like LLVM. On Thu, Nov 14, 2013 at 8:06 AM, Hongbo Zhang wrote: > On 11/13/13, 2:00 PM, Jon Harrop wrote: > >> Jeff Meister wrote: >> >>> 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. >>> >> >> Peter Zotov wrote: >> >>> Speed? :) >>> >> >> I use OCaml+LLVM for the algebraic data types, pattern matching, >> functional programming and so on. Type safety of the bindings is way down >> on the list for me. >> > > agreed, the major benefit for me compared with c++, is compile time > performance, pattern matching and toplevel -- the type safety of the > bindings is nice > but not necessary if it brings too much complexity to the API > > > Cheers, >> Jon. >> >> >> >> > > -- > 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 > --bcaec5485a986c458304eb281952 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is basically no extra complexity, just refactor= ing. The only difference is that, for example, setting the initializer for = a GlobalVariable.c statically requires a Constant.c, not just any llvalue a= s allowed by the existing bindings. I don't see this as additional comp= lexity, because you have to know the real types anyway to work with the cur= rent bindings. I'm simply making them explicit in the interface. There = is unfortunately the annoyance of frequent upcasts: to past your Constant.c= x to a function that expects a Value.c, you must write (x :> Value.c). = But that limitation of the OCaml language can be removed, and it already ha= s been in the implicit_subtyping branch. I would love to see those changes = integrated into mainline OCaml, or at least updated to work with the latest= release! :)

You guys are right that I was too sweeping with my statement= about type safety... the other features you mentioned are great reasons to= prefer OCaml, and they're important to me too. What I should have said= was, I don't want to have to sacrifice type safety of the bindings so = I can work in OCaml, especially when I see no fundamental reason why that s= acrifice is necessary. Frankly I was very surprised when I first discovered= that the bindings are so inadequate in this respect, and that no one had d= one anything about it. Maybe that's because no one cares, but I doubt i= t. It may not be the most important thing, but I see it as free help from O= Caml's type and module systems, and I'll take that help, especially= when working with such a large and complex project like LLVM.


O= n Thu, Nov 14, 2013 at 8:06 AM, Hongbo Zhang <bobzhang1988@gmail.com= > wrote:
On 11/13/13, 2:00 PM, Jon = Harrop wrote:
Jeff Meister wrote:
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.

Peter Zotov wrote:
Speed? :)

I use OCaml+LLVM for the algebraic data types, pattern matching, functional= programming and so on. Type safety of the bindings is way down on the list= for me.

agreed, the major benefit for me compared with c++, is compile time perform= ance, pattern matching and toplevel -- the type safety of the bindings is n= ice
but not necessary if it brings too much complexity to the API


Cheers,
Jon.





--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs

--bcaec5485a986c458304eb281952--