-----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-----