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.3 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 1DC55BC6B for ; Sun, 28 Oct 2007 14:34:40 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHorJEfLENaHn2dsb2JhbACOYwIBAQcEBgkg X-IronPort-AV: E=Sophos;i="4.21,338,1188770400"; d="scan'208";a="3748964" Received: from ipmail03.adl2.internode.on.net ([203.16.214.135]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Oct 2007 14:34:38 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKYsJEd5LGK+/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,338,1188743400"; d="scan'208";a="176226247" Received: from ppp121-44-98-190.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.98.190]) by ipmail03.adl2.internode.on.net with ESMTP; 29 Oct 2007 00:04:35 +1030 Subject: Re: [Caml-list] OCaml/C interface From: skaller To: David Teller Cc: Nathan Mishra Linger , caml-list@yquem.inria.fr In-Reply-To: <1193575003.6383.19.camel@Blefuscu> References: <20071026091806.GA10054@localhost> <1193575003.6383.19.camel@Blefuscu> Content-Type: text/plain Date: Mon, 29 Oct 2007 00:34:33 +1100 Message-Id: <1193578473.19122.33.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 0100,:01 annotations:01 mytype:01 mytype:01 emits:01 camlp:01 ocaml:01 notation:01 integers:01 pointer:01 sourceforge:01 char:01 char:01 wrote:01 On Sun, 2007-10-28 at 13:36 +0100, David Teller wrote: > external "C" my_native_function = "char* stuff(char* a, char* b)" > > That was just a random thought, I have no particular interest in > implementing this, but what do you think about it ? This is the basis of how Felix binds to C/C++. You need to provide ways to bind *types* as well. With experience, you'll find various property annotations are useful. Felix says stuff like: type mytype = "mytype"; fun f: int * mytype-> int = "f($1,$2)"; and emits appropriate code. Camlp4 can do the same thing probably, and emit C glue. Note your form of specification isn't as good as mine. With coding like my 'f' you specify the name and Ocaml calling convention, then the way to wrap an Ocaml call to a C call. In particular you could write: fun f: int * mytype-> int = "g($1,100,$2)+1"; The problem with your notation is that it is a bit naive: it assumes a simple correspondence between Ocaml and C calls that doesn't exist in general: you need to use a richer binding language. The actual C code would make a function which is called which does conversions based on type stuff for the arguments $1 $2 etc, and then actually emit the C code with replacements of the converted values. You need to allow for more than one kind of conversion. Concrete copying, as in integers, is not the same as a pointer based representation (abstract type). It's important not to fix one or the other but allow choices. Felix also does this: fun f: ... = " .. " requires '#include "mine.h"'; so that you can put the header file etc in with the specification. Once you use automated wrapping, it HAS to do everything because you can no longer intervene -- the only alternative is write your C glue by hand in a separate file, which is precisely what the facility here is trying to avoid. A good design goal here is .. GET RID OF int64 etc type from Ocaml. Work on the binding feature until it can be done by the user with no external C code. -- John Skaller Felix, successor to C++: http://felix.sf.net