caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Paul Snively <psnively@mac.com>
To: Jeff Henrikson <jehenrik@yahoo.com>
Cc: Mike Hamburg <hamburg@fas.harvard.edu>,
	ml-labo@epimac.org, Julien Roussel <julien.roussel@gmail.com>,
	Oliver Bandel <oliver@first.in-berlin.de>,
	caml-list@yquem.inria.fr, tipoix@free.fr
Subject: Re: OCaml && COCOA-Environment (Mac-OS-X/GUI)
Date: Thu, 24 Feb 2005 18:03:03 -0800	[thread overview]
Message-ID: <a0aa01de8f850698dd96a073e9a51089@mac.com> (raw)
In-Reply-To: <20050217071238.GA19872@hosting>

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


  parent reply	other threads:[~2005-02-25  2:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-05  0:02 Oliver Bandel
2005-02-05 16:37 ` [Caml-list] " Julien Roussel
2005-02-05 19:51   ` Mike Hamburg
2005-02-06 21:04     ` Paul Snively
2005-02-07  2:24       ` Oliver Bandel
2005-02-09 19:41         ` Mike Hamburg
2005-02-17  7:12       ` Jeff Henrikson
2005-02-18 23:41         ` [Caml-list] " art yerkes
2005-02-25  2:03         ` Paul Snively [this message]
2005-02-25  9:13           ` Oliver Bandel
2005-02-26  1:19             ` [Caml-list] " Sachin Shah
2005-03-01  6:39           ` Jeff Henrikson
2005-03-07  5:20             ` Paul Snively
2005-02-22  2:45     ` [Caml-list] " William D.Neumann
2005-02-23  0:12       ` Jacques Garrigue
2005-02-24 20:40         ` Paul Snively
2005-02-24 23:21           ` Oliver Bandel
2005-02-25 17:20             ` Mostly OT: Apple and Language Adoption was " Paul Snively
2005-02-22 10:54     ` Oliver Bandel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0aa01de8f850698dd96a073e9a51089@mac.com \
    --to=psnively@mac.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=hamburg@fas.harvard.edu \
    --cc=jehenrik@yahoo.com \
    --cc=julien.roussel@gmail.com \
    --cc=ml-labo@epimac.org \
    --cc=oliver@first.in-berlin.de \
    --cc=tipoix@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).