Re: OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Jeff Henrikson <jehenrik@yahoo.com>]

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

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.

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.

Regards,


Jeff Henrikson




On 06/02/05 13:04 -0800, Paul Snively wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Feb 5, 2005, at 11:51 AM, Mike Hamburg wrote:
> 
> >Additionally, I developed a very rudimentary binding.  It allowed the 
> >user to call Cocoa methods from O'Caml, but it had an enormous 
> >overhead: each method invocation from O'Caml had the overhead of about 
> >5 method calls from the C glue.  There was a (somewhat more efficient) 
> >Cocoa-to-O'Caml call method, but I don't remember if I ever finished 
> >it.
> >
> >Paul Snively, Nick Burlett and I were working on a more efficient 
> >bridge, by means of parsing Cocoa headers to automatically generate 
> >typed bindings which would look like objects to O'Caml, but the 
> >project fizzled without any real results.  Perhaps someone with more 
> >FrontC knowledge could resurrect it.  The existing code is not 
> >strongly typed: you can attempt to pass the wrong number or type of 
> >arguments to a method, and it will raise an O'Caml exception instead 
> >of rejecting it at compile time.
> >
> >The O'Caml-to-Cocoa bridge is not online, but I can send you what code 
> >we have if you want.
> >
> 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, but I confess to having no real roadmap for how 
> to get there, and my Copious Free Time(tm) is rather torn between 
> wanting to get O'Caml going natively on OS X and wanting to plow 
> through TAPL and now ATITAPL and master MetaPRL and concentrate on 
> learning how to design modern programming languages.
> 
> But at the very least, I'd love to see the current state of your code. 
> :-)
> 
> >Mike Hamburg
> >
> Many thanks and best regards,
> Paul
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (Darwin)
> 
> iEYEARECAAYFAkIGhmIACgkQO3fYpochAqJ17QCdFUWvJ3ul5nvsqb7wp/GZ8khp
> fVcAniTDjb+ksXRgsxAT/ty9qwCyNdR2
> =bSuT
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs