From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id F371CBC6B for ; Sat, 12 Jan 2008 16:02:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQrAK9liEfUnw6Ea2dsb2JhbACCNI1VCwQGEBIHlxI X-IronPort-AV: E=Sophos;i="4.24,275,1196636400"; d="scan'208";a="5971879" Received: from pih-relay05.plus.net ([212.159.14.132]) by mail2-smtp-roc.national.inria.fr with ESMTP; 12 Jan 2008 16:02:15 +0100 Received: from [80.229.56.224] (helo=beast.local) by pih-relay05.plus.net with esmtp (Exim) id 1JDhsE-0007Tn-9l for caml-list@yquem.inria.fr; Sat, 12 Jan 2008 15:02:14 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Performance questions, -inline, ... Date: Sat, 12 Jan 2008 14:22:56 +0000 User-Agent: KMail/1.9.7 References: <200801031128.30183.ober.14@osu.edu> <200801071958.23681.jon@ffconsultancy.com> <200801080920.04187.ober.14@osu.edu> In-Reply-To: <200801080920.04187.ober.14@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801121422.56951.jon@ffconsultancy.com> X-Spam: no; 0.00; -inline:01 interfacing:01 compiler:01 ocaml:01 ffi:01 ocaml:01 bindings:01 ffi:01 gtk:01 gtk:01 c-style:01 bytecode:01 compiler:01 gripe:98 frog:98 On Tuesday 08 January 2008 14:20:03 Kuba Ober wrote: > If you can do some code generation, it shouldn't be a big deal to implement > even some very complex ABIs, say interfacing to C++ libraries. As long as > you can cleanly run your language at compile time (like lisp does), and as > long as the compiler provides a documented way to pop assembly into the > code, you can have a nice language that can, in "natively compiled" output, > interface say with Qt. Yes. This is one of the features that I would dearly love but it is also another one of the features that doesn't count as research so you're never likely to find it in a research implementation of a language like OCaml. F# has a fantastic FFI in comparison, for example. Perhaps the best solution for OCaml is to interface with a popular dynamic language and borrow its bindings. I believe Richard Jones' Perl interface does this, although I've never used it myself. The obvious flaw is that you end up with a very fast compiled language with a very slow interface boundary. That's fine for many cases, of course, but I'm particularly interested in high-performance numerics and visualization which really benefit from a high-performance FFI. > IMHO, the latter is now a few years ahead of GTK, and is only gaining the > advantage as time passes. May I ask what features Qt has that GTK does not? My only gripe with GTK is that it is very slow and, consequently, I always seem to end up migrating my GUI code to OpenGL. I still think an OpenGL-based GUI written in OCaml would be great... > Languages such as OCaml > sorely lack in nontrivial ABI department - there's no reason to have to > write (or even generate) C-style binding code for say Qt just to use it in > OCaml. Both bytecode compiler and native code compiler should have a > pluggable ABI-generator scheme where they can interface with C++ (at > least). Another way to go about it would be to machine-translate C++ > libraries to OCaml. I'd be happy to interface with C and have no real preference about C++ myself. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e