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 VAA17729; Wed, 29 May 2002 21:25:27 +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 VAA17677 for ; Wed, 29 May 2002 21:25:26 +0200 (MET DST) Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4TJPOn17763; Wed, 29 May 2002 21:25:24 +0200 (MET DST) Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g4TJPMZr027428; Thu, 30 May 2002 05:25:22 +1000 (EST) Received: from ozemail.com.au (ppp101.dyn17.pacific.net.au [61.8.17.101]) by wisma.pacific.net.au with ESMTP id FAA29185; Thu, 30 May 2002 05:25:20 +1000 (EST) Message-ID: <3CF52B1F.2050004@ozemail.com.au> Date: Thu, 30 May 2002 05:25:19 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel de Rauglaudre CC: Ocaml Subject: Re: [Caml-list] Possible use for camlp4 References: <3CEF08ED.80407@baretta.com> <20020525125530P.garrigue@kurims.kyoto-u.ac.jp> <3CF28495.20102@baretta.com> <3CF27A8F.2000306@ozemail.com.au> <20020527213326.F9870@verdot.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Daniel de Rauglaudre wrote: >>Hmm.. can camlp4 generate C? >> >What do you mean by "generate C"? Can you specify, give examples? > Input: CBINDING fred:int -> int = fred($1) ENDBINDING output #1: extern int fred_binding(int x) { return fred(x); } /* generated C function */ output #2: external fred:int ->int = "fred_binding"; (* ocaml stub *) 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] Just as an example: the keyword 'interruptible' might mean to use enter/leave blocking section macros. That is: my suggestion is to design a language CamlCGlue, which generates C code to bind ocaml to C libraries, and implement it using camlp4. BTW: this thought was prompted by the debate as to whether camlp4 belongs in the standard distribution or not, and unrelated discussion about building bindings to C libraries. 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? -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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