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