From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 666ACBC75 for ; Fri, 25 Feb 2005 03:03:41 +0100 (CET) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.70]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j1P23ddU011371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Feb 2005 03:03:41 +0100 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/MantshX 4.0) with ESMTP id j1P23PEJ028417; Thu, 24 Feb 2005 18:03:25 -0800 (PST) Received: from [192.168.1.100] (dsl092-032-215.lax1.dsl.speakeasy.net [66.92.32.215]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j1P23Htf007557; Thu, 24 Feb 2005 18:03:20 -0800 (PST) In-Reply-To: <20050217071238.GA19872@hosting> References: <20050205000208.GB1364@first.in-berlin.de> <3a2f4a1305020508377ec6ddaf@mail.gmail.com> <617f41a9a7ef08a96d3bd59b00a9ae47@mac.com> <20050217071238.GA19872@hosting> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Mike Hamburg , ml-labo@epimac.org, Julien Roussel , Oliver Bandel , caml-list@yquem.inria.fr, tipoix@free.fr From: Paul Snively Subject: Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) Date: Thu, 24 Feb 2005 18:03:03 -0800 To: Jeff Henrikson X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619.2) X-Miltered: at nez-perce with ID 421E877B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 hash:01 henrikson:01 wrote:01 ffi:01 bindings:01 lexer:01 ast:01 parser:01 real-world:01 parsing:01 stdio:01 dependencies:01 gcc:01 ast:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jeff! On Feb 16, 2005, at 11:12 PM, Jeff Henrikson wrote: >> Mea culpa. I'm still very interested. I can't help but think that >> extending Jeff Henrikson's Forklift FFI to handle Objective-C and >> marrying that to an (improved? revised?) version of your bindings >> wouldn't be a big win > > A heads up with Forklift: > > I have been stuck lately in lexer hell. Frontc has a good AST, but > the parser is not designed to parse real-world nasty header files. > There are lots of pragmas such as __builtin_va_list which will crash > when parsing the linux stdio.h and etc. To my knowledge, the best > work with this has been done by the Cil team at UC Berkeley. > Unfortunately, the Cil team chose to fork the frontc sources and not > contribute a backport that I can tell. The dependencies are very > intertwined. > Is this still true for Frontc 3.1? It claims to handle GCC extensions, but I'm sure that keeping up to date with them is some work. > Forklift has a frontend now (more on that below) which is based on > Cabs (the frontc AST). I do not want to use the cil oop design > because it will make me deal with semantics, and I want to keep frontc > a strictly syntactic device with some simple generation-time type > equality checking. Cil also comes with some architecture specific > config tests for performance counters and such which would make for > configure script bloat. So after about three weekends of getting > burned out on a cycle of ripping out dependencies, not quite > finishing, and then forgetting where I was,I have a patch to extract > the modified frontc from cil. Unfortunately, in the meantime, Mr. > Casse has gone from 2.0 when cil forked to a version 3.1. A > superficial inspection did not make clear to me the nature of the > upgrades, except that diff was freaking out about reordered code. > > I have an email out with Mr. Casse regarding how he feels about > merging these changes. An Obj-C and/or C++ extension should > preferably begin with a "blessed" starting point. > I agree, and wonder whether there's consensus as to whether 3.1 should be that starting point, or whether we should (need to, for Forklift's sake?) integrate the Cil and 3.1 changes. > About the new frontend: it's based on a macro expansion which pattern > matches C types. The following returns a caml AST representing a > function which takes an argument list, looks for a pointer type along > with an int named "length", and returns a string printing the pointer > type and length variable. The idea being we think we have found a > high level array object. MPBT_PERM means to match in any order, but > there are patterns for consecutive and ordered matching too. > > (easy_pat_bt_expand (MPBT_PERM > [false,None,(BT_PTR (PBT_BIND "t")); > true,Some (PIDEN_LIT("length")),(BT_INT(PNO_SIZE,PNO_SIGN))]) > (<:expr< "array " ^ (string_of_type t) ^ " has length " ^ > (int_of_string len) >>));; > > Now all I need is a C-like camlp4 extension so that I can get the > above expression with something like > > MATCH_RULE function_proto with > PERM{t* _; int length} -> > "array " ^ (string_of_type t) ^ " has length " ^ > (int_of_string len) > > The camlp4 part is straightforward but still needs doing. This > pattern matching syntax will couple nicely with the .5 release, which > was really just a backend typestub composing algebra. The common case > of course being that the right hand side of a MATCH_RULE command > returns an n->k dimensioned typestub, meant for attatching to the > variables which were matched. > > I will be posting to the list when I have put it back together. I am > using an OS X powerbook as we speak and would love a contribution for > ObjC. > This sounds very nice! How would you suggest that we proceed toward Objective-C coverage in conjunction with your other requirements and observations about the status of Frontc and Cil? > Regards, > > > Jeff Henrikson > Best regards, Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iEYEARECAAYFAkIeh2EACgkQO3fYpochAqL9jgCfRGDgiI4JQKt3hVWEo7ZGAv3l BlIAoKe99JPLBJN/1y4cwOqy00xKQtPH =HKjL -----END PGP SIGNATURE-----