From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA18346; Thu, 30 May 2002 04:43:30 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA22750 for ; Thu, 30 May 2002 04:43:30 +0200 (MET DST) Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4U2hRn00714 for ; Thu, 30 May 2002 04:43:27 +0200 (MET DST) Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17]) by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id LAA32325; Thu, 30 May 2002 11:42:12 +0900 To: skaller@ozemail.com.au Cc: caml-list@inria.fr Subject: Re: [Caml-list] Possible use for camlp4 In-Reply-To: <3CF52B1F.2050004@ozemail.com.au> References: <3CF27A8F.2000306@ozemail.com.au> <20020527213326.F9870@verdot.inria.fr> <3CF52B1F.2050004@ozemail.com.au> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020530114206Z.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 30 May 2002 11:42:06 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: John Max Skaller > The idea is a file of hand written bindings which generate the C code > necessary to wrap a C library. There are two outputs: the C glue code > and the ocaml binding definitions. > > The point is to use camlp4 to make it easier to write the C glue code, > by inventing some language syntax which knows about the garbage > collector, heap format, the macros needed to do all that, etc. > > That is, the glue code isn't generated *automatically* from a C interface, > like with SWIG. Instead, you have to write the glue code by hand, > as you do now. The difference is that you write it in a slightly > higher level language than the ugly and error prone C/Ocaml macros > system. In addition, the 'simplified' way of using those macros is sometimes > very inefficient. [eg, making parameters and local variables gc roots > when there is no need] Why not. > If there is one thing that Ocaml is perceived as needing more > than anything else for industrial use, it's bindings to more C libraries. > At present, writing them is very very expensive, and maintaining > them is an even worse problem if the target C library is evolving > eg GTK. So .. why not use ocamlp4 to help reduce the problem? This can help, but a frequent misconception is that gluing is the main problem with external libraries. It is for beginners, but for experimented programmers, with a good set of C macros and sane habits, that's the easy part. Even cooperating with the GC is not that hard (as long as you don't try to optimize too much). What is really difficult is fancy callback systems, and abstracting the invariants from the C API (including allocation problems). Both are hard problems, with very little automated support. In both cases you must understand how the library works from informal explanations (or quite often reading the source code) before starting to code. If the library is very regular, or uses a specific language like Tcl/Tk, you may end up with some way to speed-up the process, but in general you need to go into details, and there are exceptions. So, yes for making things easier, like ocamlidl does already for instance, but there are no miracles: as long as the external world is not strongly typed in a language we can understand, the process is going to be painful. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners