Version française
Home     About     Download     Resources     Contact us    
Browse thread
Performance questions, -inline, ...
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Performance questions, -inline, ...
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