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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 102CC7EE25 for ; Tue, 12 Nov 2013 15:13:45 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; 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.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYhAMc2glKwOmd9/2dsb2JhbABZgz+DSIZHoHuCCpJagT10giUBAQQBIw8BBTYQBwQEBQIRBAEBAQICCRoDAgIsGQEJCAYTCAqHXQMJCgmQI5teiGkDiT+BKYgOhi8GgmWBRgOJPIlWhiyQW4MrNw X-IPAS-Result: AqYhAMc2glKwOmd9/2dsb2JhbABZgz+DSIZHoHuCCpJagT10giUBAQQBIw8BBTYQBwQEBQIRBAEBAQICCRoDAgIsGQEJCAYTCAqHXQMJCgmQI5teiGkDiT+BKYgOhi8GgmWBRgOJPIlWhiyQW4MrNw X-IronPort-AV: E=Sophos;i="4.93,685,1378850400"; d="scan'208";a="42338208" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail2-smtp-roc.national.inria.fr with ESMTP; 12 Nov 2013 15:13:43 +0100 Received: by mail.whitequark.org (Postfix, from userid 33) id 7BE7410BDF5; Tue, 12 Nov 2013 18:13:42 +0400 (MSK) To: X-PHP-Originating-Script: 1000:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 12 Nov 2013 18:13:42 +0400 From: Peter Zotov In-Reply-To: References: <010801cedc66$0425bcc0$0c713640$@ffconsultancy.com> <14f25a35d63f2b6ce6185d86dc66d2bd@whitequark.org> <012101cedc76$1665b920$43312b60$@ffconsultancy.com> Message-ID: X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/0.8.6 Subject: Re: [Caml-list] LLVM OCaml bindings Jeff Meister писал 12.11.2013 07:44: > 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. Speed? :) Actually, OCaml has much more type safety than C or bindings of LLVM to dynlangs (Ruby, etc). Ruby bindings didn't even check if I pass lltype where llvalue is expected, and there was no easy way to do it. > 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? They wrote their own C wrappers using the C++ API. I'm currently pushing them upstream, slowly. Haskell folks probably didn't do that because it's somewhat of a pain if you're not an LLVM committer. > > 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 >> significantly 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 писал 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 [1] >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners [2] >> Bug reports: http://caml.inria.fr/bin/caml-bugs [3] > > > > Links: > ------ > [1] https://sympa.inria.fr/sympa/arc/caml-list > [2] http://groups.yahoo.com/group/ocaml_beginners > [3] http://caml.inria.fr/bin/caml-bugs -- WBR, Peter Zotov.