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

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

[Oliver Bandel]

Hello,

is there a COCOA-Binding/Lib for OCaml?

I want to do GUI-stuff for data-input by users
as well as 3D-graphics (OpenGL-like) on Mac-OS-X.
And I would be sooooo happy, it can be made with
OCaml.
Not that Objective-C or is a bad thing.... but
doing the whole stuff in OCaml is preferred.

Is there a library to use Ocaml with Mac-OS-X' GUIs?


TIA,
  Oliver

-- 

  "Der Kopf ist rund, damit das Denken die Richtung wechseln kann."
                                                     (Francis Picabia)

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Julien Roussel]

Hello Oliver,

There is a COCOA-CAML binding developed by Jean-Baptiste Poix, an
alpha version is available at
http://labo.epimac.org/article.php3?id_article=7.

Sorry but the page is still in french, an english version and a
documentation will be available soon. You can download an example at
http://labo.epimac.org/IMG/gz/first_cococaml.tar.gz.

Please do not hesitate to contact Jean-Baptiste (tipoix@free.fr) with
any questions.

Regards, Julien.


On Sat, 5 Feb 2005 01:02:08 +0100, Oliver Bandel
<oliver@first.in-berlin.de> wrote:
> 
> Hello,
> 
> is there a COCOA-Binding/Lib for OCaml?
> 
> I want to do GUI-stuff for data-input by users
> as well as 3D-graphics (OpenGL-like) on Mac-OS-X.
> And I would be sooooo happy, it can be made with
> OCaml.
> Not that Objective-C or is a bad thing.... but
> doing the whole stuff in OCaml is preferred.
> 
> Is there a library to use Ocaml with Mac-OS-X' GUIs?
> 
> TIA,
>   Oliver
> 
> --
> 
>   "Der Kopf ist rund, damit das Denken die Richtung wechseln kann."
>                                                      (Francis Picabia)
> 
> _______________________________________________
> 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
>

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Mike Hamburg]

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.

Mike Hamburg

On Feb 5, 2005, at 11:37 AM, Julien Roussel wrote:

> Hello Oliver,
>
> There is a COCOA-CAML binding developed by Jean-Baptiste Poix, an
> alpha version is available at
> http://labo.epimac.org/article.php3?id_article=7.
>
> Sorry but the page is still in french, an english version and a
> documentation will be available soon. You can download an example at
> http://labo.epimac.org/IMG/gz/first_cococaml.tar.gz.
>
> Please do not hesitate to contact Jean-Baptiste (tipoix@free.fr) with
> any questions.
>
> Regards, Julien.
>
>
> On Sat, 5 Feb 2005 01:02:08 +0100, Oliver Bandel
> <oliver@first.in-berlin.de> wrote:
>>
>> Hello,
>>
>> is there a COCOA-Binding/Lib for OCaml?
>>
>> I want to do GUI-stuff for data-input by users
>> as well as 3D-graphics (OpenGL-like) on Mac-OS-X.
>> And I would be sooooo happy, it can be made with
>> OCaml.
>> Not that Objective-C or is a bad thing.... but
>> doing the whole stuff in OCaml is preferred.
>>
>> Is there a library to use Ocaml with Mac-OS-X' GUIs?
>>
>> TIA,
>>   Oliver
>>
>> --
>>
>>   "Der Kopf ist rund, damit das Denken die Richtung wechseln kann."
>>                                                      (Francis Picabia)
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
>

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Paul Snively]

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

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Oliver Bandel]

Hi,

I had looked shortly at the code... but it seems I have to learn a lot
more of OCaml-C-Binding-stuff as well as Objective-C.
So I started to learn again Objective-C in more detail.

As far as I can see, the Classes of the Cocoa-Lib are very
powerful!!!

I will start to write some small Applications in Objective-C under OS-X
as soon as possible. But bigger stuff I would prefer to write in OCaml.

If I maybe will have enough experience with ObjC and COCOA,
I will try to marriage it with the Ocaml-C-binding (but this
is new to me too).

If I may have some time to visit the code,  or to test it with
expermimental programs, I can look into it.
But now it seems to me, that I have to learn the basics of these
different worlds in more detail.

I came from ANSI-C and have done the most work on Linux. Then I have done
a lot of Perl-programming on Linux too.

But the Mac-OS-World is different (but very impressing, what they are doing
there... they seem to have a lot of that NeXt-Step-Stuff integrated into OS-X!)


I hope that there are some more people out there who are
interested to - maybe - start a project to integrate
COCOA and OCaml. It seems to me, that a powerful library for
OS-X-GUI (COCOA) for OCaml could be a nice thing for many people.

Are there more OS-X developers or are there more OCaml-developers?
And how many OCaml-developers are working at OS-X?
And if there woule be such a binding... ?!

Best regards....
       ... I hope to have enough time for doing more ObjC...


Ciao,
   Oliver


On Sun, Feb 06, 2005 at 01:04:20PM -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-----
> 

-- 
"Here at michigan state university, my computational linguistics professor
 had us learn ocaml for the class and we used it exclusively. I like it so
 much better than c++! Hope this helps." (Jeff Shaw on caml-list)

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Mike Hamburg]

On Feb 6, 2005, at 9:24 PM, Oliver Bandel wrote:

> Hi,
>
> I had looked shortly at the code... but it seems I have to learn a lot
> more of OCaml-C-Binding-stuff as well as Objective-C.
> So I started to learn again Objective-C in more detail.
>
> As far as I can see, the Classes of the Cocoa-Lib are very
> powerful!!!

They are certainly quite powerful, but their garbage collection is 
reference-counted, which makes it rather painful.  The language is also 
extremely verbose, and has little support for higher-order functions.  
That's why I prefer to write in O'Caml, and largely why I wrote the 
O'Caml to Cocoa bridge in the first place.

> I will start to write some small Applications in Objective-C under OS-X
> as soon as possible. But bigger stuff I would prefer to write in OCaml.
>
> If I maybe will have enough experience with ObjC and COCOA,
> I will try to marriage it with the Ocaml-C-binding (but this
> is new to me too).
>
> If I may have some time to visit the code,  or to test it with
> expermimental programs, I can look into it.
> But now it seems to me, that I have to learn the basics of these
> different worlds in more detail.
>
> I came from ANSI-C and have done the most work on Linux. Then I have 
> done
> a lot of Perl-programming on Linux too.
>
> But the Mac-OS-World is different (but very impressing, what they are 
> doing
> there... they seem to have a lot of that NeXt-Step-Stuff integrated 
> into OS-X!)

Yes, OS X is essentially an improved NeXTSTEP, running on a Mach kernel 
with BSD bindings.  I've been quite impressed at what they managed to 
build on a UNIX, though... it blows KDE out of the water in most 
respects (in my opinion).

> I hope that there are some more people out there who are
> interested to - maybe - start a project to integrate
> COCOA and OCaml. It seems to me, that a powerful library for
> OS-X-GUI (COCOA) for OCaml could be a nice thing for many people.

Agreed.  What the project would need would be people familiar with FFI 
tools such as Forklift, as the existing bindings are not type-checked 
and are slow.

> Are there more OS-X developers or are there more OCaml-developers?
> And how many OCaml-developers are working at OS-X?
> And if there woule be such a binding... ?!
>
> Best regards....
>        ... I hope to have enough time for doing more ObjC...
>
>
> Ciao,
>    Oliver

Mike Hamburg
>
> On Sun, Feb 06, 2005 at 01:04:20PM -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-----
>>
>
> -- 
> "Here at michigan state university, my computational linguistics 
> professor
>  had us learn ocaml for the class and we used it exclusively. I like 
> it so
>  much better than c++! Hope this helps." (Jeff Shaw on caml-list)
>
> _______________________________________________
> 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
>

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

[Jeff Henrikson]

> 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

Re: [Caml-list] Re: OCaml && COCOA-Environment (Mac-OS-X/GUI)

[art yerkes]

Jeff Henrikson <jehenrik@yahoo.com> wrote (lines wrapped):
> 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.

I wonder if the SWIG parser (which is very dirty, but quite permissive)
might be useful in helping to buildup frontc.  I like the idea of frontc
but am using SWIG for bindings mainly because it works on a remarkable
variety of input.  Even though I'm nearly finished with the static types
fork I've promised (now written in ocaml), it still relies on SWIG -xml
to generate the input.  A purer solution would be preferrable if it could
be tuned to accept more input than frontc does now.

I'd be willing to work with you to try to convert the SWIG parser, if 
you're interested in collaborating.  Maybe we can choose some unlanguaged
representation that can be built into both SWIG and frontc ... then it'd 
be possible for both to share bug fixes too (SWIG regularly gets new
hairy template expansion test cases).

Art
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[William D.Neumann]

On Feb 5, 2005, at 12:51 PM, Mike Hamburg wrote:

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

Have any of you taken a look at the work done for the Haskell to 
Objective-C Binding <http://hoc.sourceforge.net/>.  It seems to be a 
bit stagnant, but they may have some insight to offer...

William D. Neumann

"You've got Rita Marlowe in the palm of your hand."
"Palm of my hand?  You haven't seen Rita Marlowe..."

		-- Will Success Spoil Rock Hunter?

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Oliver Bandel]

On Sat, Feb 05, 2005 at 02:51:20PM -0500, Mike Hamburg wrote:
[...]
> 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 big advantage in flexibility is the big disadvantage in
secure programming: The late binding of Objective-C seems
to be a good thing for many people and many tasks, because
runtime loading of code means a lot of flexibility.
But as I started to jump into ObjC in more detail during the last
few weeks, with one of my first examples I run into that advangage's
traplike behaviour: Compiling code was done without any errors/warnings.
After running the code, I got the message that the program could not
run one of the methods...

...this was in a really small example. And this is, where the static
behaviour of OCaml has told me that something was wrong.
When extrapolate this late binding problem to bigger, big,
huge, very huge code base, then it is clear to me, what aproach
will yield to safer programming and faster programming (because
you don't need to test the running program to find, what you
also have found earlier - during compilation time).


Nevertheless yields ObjC-programming (because of it's flexibility)
very short development times.

But Ocaml also yields to rapid development. :)

One big advantage - at least in the COCOA-environment - is,
that ObjC can use a lot of powerful libraries.
This also is a reason for rapid developement, so it's not only
the language itself.

OK, long words for what I started to say here: The problem with
exceptions instead of compile-time errors may be caused by using
the id-type instead of statically using specialized types for the
object-allocation?!


Maybe it would be a good idea to write an OCaml-program that
generates the glue-code between OCaml and ObjC/COCOA?!


Ciao,
   Oliver

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Jacques Garrigue]

From: "William D.Neumann" <wneumann@cs.unm.edu>
> Have any of you taken a look at the work done for the Haskell to 
> Objective-C Binding <http://hoc.sourceforge.net/>.  It seems to be a 
> bit stagnant, but they may have some insight to offer...

This actually looks pretty impressive.
And it isn't really stagnant: their approach is to generate everything
automatically, so once it works, there are not many changes left to
do. Yet they could do with a bit more documentation (but I shouldn't
be the one to say so :-)

So they have this wonderful interface compiler, which slurps all the
objective C headers, and produces a strongly typed Haskell interface.
With a bit of syntactic sugar, you end up with something you can
actually write in; actually you write objective C with haskell syntax,
which is a bit weird, but works.

Of course, there is a catch: the generated interface is huge.
So you end up with this 172-line haskell application (a simple
editor), which compiles to a 11MB binary (not including the
gnustep/cocoa shared libraries). The binary libraries (*.a) they
install sum up to a whooping 33MB!

I suppose the same kind of integration could be done with ocaml.
In particular Objective C is dynamic enough that you can do lots of
things with a tiny runtime support, and then introduce all your types.
The problem is that it's not clear whether it would match nicely with
the ocaml object system.

Cheers,

Jacques Garrigue

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 22, 2005, at 4:12 PM, Jacques Garrigue wrote:

> This actually looks pretty impressive.
> And it isn't really stagnant: their approach is to generate everything
> automatically, so once it works, there are not many changes left to
> do. Yet they could do with a bit more documentation (but I shouldn't
> be the one to say so :-)
>
> So they have this wonderful interface compiler, which slurps all the
> objective C headers, and produces a strongly typed Haskell interface.
> With a bit of syntactic sugar, you end up with something you can
> actually write in; actually you write objective C with haskell syntax,
> which is a bit weird, but works.
>
This is exactly what I have in mind: take advantage of Forklift's 
external annotations to header files. So: revise Forklift to parse 
Objective-C headers, write (external) annotations to Apple's headers, 
and use Forklift to generate the O'Caml wrappers. Indeed, part of the 
point is very much to end up in a position where changes Apple makes to 
the headers necessitate hopefully minor revisions to the annotations 
and an automated regeneration.

> Of course, there is a catch: the generated interface is huge.
> So you end up with this 172-line haskell application (a simple
> editor), which compiles to a 11MB binary (not including the
> gnustep/cocoa shared libraries). The binary libraries (*.a) they
> install sum up to a whooping 33MB!
>
Ouch! Is there no dead-code stripping?

> I suppose the same kind of integration could be done with ocaml.
> In particular Objective C is dynamic enough that you can do lots of
> things with a tiny runtime support, and then introduce all your types.
> The problem is that it's not clear whether it would match nicely with
> the ocaml object system.
>
Mike Hamburg got some distance with his runtime library, which 
naturally relied on Obj.magic. It seemed relatively tight and elegant, 
but of course he's since commented on some runtime overhead concerns 
that, IIRC, he believes might be ameliorated by having better type 
information, which presumably would come from the FFI. So we seem to be 
at something of a Catch-22, at least until some concrete progress on 
deriving type information via an FFI is accomplished. I note with 
interest Jeff Henrikson's comments and regret that I have not yet had 
sufficient time to investigate them beyond reading them. Hopefully this 
weekend will provide some time to follow up.

> Cheers,
>
> Jacques Garrigue
>
> _______________________________________________
> 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
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkIeO9cACgkQO3fYpochAqJttQCgyWwDtq8zJbp4iAGNkyDWQIOL
IQ4An2fV2lQezGjzgjVdfvUBkrOB8q83
=1S2R
-----END PGP SIGNATURE-----

Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Oliver Bandel]

On Thu, Feb 24, 2005 at 12:40:46PM -0800, Paul Snively wrote:
[...]
> This is exactly what I have in mind: take advantage of Forklift's 
> external annotations to header files. So: revise Forklift to parse 
> Objective-C headers, write (external) annotations to Apple's headers, 
> and use Forklift to generate the O'Caml wrappers. Indeed, part of the 
> point is very much to end up in a position where changes Apple makes to 
> the headers necessitate hopefully minor revisions to the annotations 
> and an automated regeneration.


Apropos Apple.... when M$ creates F# out of Ocaml,
why not to trigger Apple to create sometging like
BackendObjects or ScientificObjects (as complementary to
WebObjects) out of OCaml on OS-X?!

Maybe we should trigger Apple for this?!

If not, they will use Objective-C and Java and nothing else.


Ciao,
   Oliver

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

[Paul Snively]

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

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

[Oliver Bandel]

What is Frontc and what is Cil - in a few words?

TIA,
  Oliver

Mostly OT: Apple and Language Adoption was Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Oliver!

On Feb 24, 2005, at 3:21 PM, Oliver Bandel wrote:

> Apropos Apple.... when M$ creates F# out of Ocaml,
> why not to trigger Apple to create sometging like
> BackendObjects or ScientificObjects (as complementary to
> WebObjects) out of OCaml on OS-X?!
>
> Maybe we should trigger Apple for this?!
>
> If not, they will use Objective-C and Java and nothing else.
>
Boy oh boy, where to begin with this?

I was at Apple from 1989-1991, when John Sculley was CEO and at the 
time that Jean-Louis Gasseé was pushed out. At this time, Apple 
Computer still had an Advanced Technology Group that did pure research, 
and also had Apple Fellows who sometimes drove initiatives that 
involved programming languages. Some folks in ATG really liked Coral 
Common Lisp, so Apple bought Coral Software and thus Coral Common Lisp 
became Macintosh Common Lisp. Alan Kay was an Apple Fellow, so he and 
his colleagues created Squeak Smalltalk. Allen Cypher, author of "Watch 
What I Do," was in ATG, so we got projects like KidSim, which became 
Cocoa (not to be confused with Mac OS X's Cocoa APIs, of course). The 
Newton became an active project, and that prompted the development of 
Dylan and NewtonScript.

Fast forward a few years, and MCL gets sold off, the Newton flops, 
Dylan gets canceled, Kay and Squeak leave Apple, Cocoa gets canceled, 
Steve Jobs returns and "Steves" not only whatever research projects are 
left, but also some arguably core technologies such as Quickdraw 3D. 
What Apple got instead was more standards-compliant technology such as 
OpenGL, a better-known base in the form of FreeBSD-based Mac OS X but 
with the Carbon and Cocoa APIs on top of it, and more focus on how to 
actually innovate in the marketplace: iPod and iTunes, iMac, Mac 
Mini... Oh, and a return to profitability during some of the personal 
computing market's toughest years. It's also interesting to note that 
several things that Apple dropped have nevertheless lived: Dylan is 
kind of sputtering along thanks to heroic efforts by the Gwydion Dylan 
team and the work of the former Functional Objects, Inc.; Squeak is 
extremely healthy; MCL is still the best Common Lisp on any platform; 
Quesa is a slowly-evolving but quite nice reimplementation of Quickdraw 
3D atop OpenGL...

Culturally, my read is that Apple now has an extreme aversion to taking 
on big promotional jobs, especially about languages: the Dylan debacle 
scarred them. Market pressures forced them to backpedal from their 
initial stance toward developers that Objective-C and Cocoa were the 
"real" Mac OS X APIs and Carbon was merely a transitional API to the 
reality that Carbon must provide access to virtually all Mac OS X 
capabilities, e.g. HIViews and Sheets, and Objective-C and Cocoa are 
marginal, Mac-OS-X-only tools for true believers. Later still they had 
to go so far as to add "Objective-C++" to their version of GCC so that 
developers could write their cross-platform core code in C++, and write 
only the UI layer in Objective-C, which then needed to be able to call 
the C++ core.

Finally, it's been a long time since Apple was commanding 500% profit 
margins and could afford to throw money away on research projects. Sad, 
but true.

So for a variety of political, historical, economic, and technical 
reasons, it's not at all realistic to expect Apple to pursue anything 
involving languages other than the absolutely mainstream: arguably the 
only reason they support Objective-C is that it and OpenStep already 
existed and were relatively mature at the time of the NeXT acquisition. 
Java made it for a couple of reasons: it's plenty mainstream enough, 
and the relationship between the Java runtime model and Objective-C 
runtime model is sufficiently incestuous that there's some leverage to 
be had by having them both.

To try to bring this back home, this is why folks like Mike Hamburg and 
myself are putting some thought into how to marry O'Caml and Cocoa 
(which, by definition, includes the Objective-C runtime model). We'd 
like to have something resembling the fluidity of Java <-> Objective-C, 
but lacking reflection, we can't exactly, so on one hand we have to 
have Mike's Obj.magic magic, and on the other we need something very 
much like, if not exactly, Jeff Henrikson's Forklift magic. So we're 
left with a bit of a transcontinental railroad project, but with a lot 
of elbow grease and faith, hopefully the result will be nice, typesafe 
O'Caml modules reflecting the entirety of Apple's Cocoa APIs.

And then maybe we can come up with functorized modules providing a 
consistent API to Cocoa, Win32, or lablgtk... ;-)
>
> Ciao,
>    Oliver
>
> _______________________________________________
> 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
>

Best regards,
Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkIfXnEACgkQO3fYpochAqJhCQCbB6mWNrMZIHCWI8jTZM1BCC/A
RIwAnRO6xoORB6hETMzR52x6/BA4h4iY
=sp7O
-----END PGP SIGNATURE-----

Re: [Caml-list] Re: OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Sachin Shah]

I recommend looking at:

FrontC: http://casse.hugues.free.fr/projects/frontc.html
CIL: http://manju.cs.berkeley.edu/cil/

Regards,

Sachin.

On Fri, 25 Feb 2005 10:13:27 +0100, Oliver Bandel
<oliver@first.in-berlin.de> wrote:
> What is Frontc and what is Cil - in a few words?
> 
> TIA,
>  Oliver
> 
> _______________________________________________
> 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
>

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

[Jeff Henrikson]

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

Upon superficial examination, the Frontc 2.0 -> 3.1 changes seem to mostly revolve around XML output.  The Cil frontc changes are more about parsing header files "in the wild".  Look at the Cil manual chapter 17 for the level of energy put into parsing messy stuff:

http://manju.cs.berkeley.edu/cil/cil017.html

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

Well, I see three possible paths.  

1) get Frontc and Cil Frontc merged.  Extend the ast and parser for Obj-C and/or C++.  I know C++ much better than ObjC, but my sense is that ObjC is easier for this.

2) gccxml is a patch for gcc made for a java C++ stub generator.  The idea is that you specify some flags to gcc and it spews XML of the parse tree.  gccxml was build for doing C++, so there may be some additions necessary to get all the ObjC primitives.  Below I attach some output from gccxml on the semi-commercial C++ 3D toolkit Nebula2.  Messy as you can see, but vastly easier than dealing with raw text.  I personally mourn the fact that massive amounts of open source labor is wasted rewriting parsers.  In my mind a parser is a generic thing 

3) yaxx is an extension to yacc which takes any .y file, and generates a modified C program which outputs .xml and a .dtd instead of just running.  This means that one can take, for example the gcc .y file, and get a .xml output C program without modifying gcc.  I really like this approach, the beauty is that it holds promise for maybe someday not needing to write a parser for every last target language.  (It seems wrong to me that we need an ocamlyacc to begin with.  There needs to be available some standard behavior which ignores the actions of a .y file and just spews an AST.  Not to mention tree walkers and other useful things.)  They have tried the gcc parser hack, and the comments say it is supposed to handle C and Obj-C (not C++?) but I can't get that part to work.  I can get the ansic, sql and java parts to work.  I copy paste below xml output for the ansi parser.  Incidentally, there's some incompatibility in the build for darwin, I needed to use a linux box.  If you search and replace all instances of stdout to another identifier in the generated ansic/gram.tab.c, it compiles on darwin but I haven't checked if the behavior is right.

Any of the three solutions basically entail getting the output back to a Cabs (frontc) similar representation.  It will be necessary to add a named attributes for parent class, language and so on, but that would be my basic strategy.

Cheers,


Jeff


gccxml on nebula2 test:


****************************gfx2/nmesh2.h***********************************

class N_PUBLIC nMesh2 : public nResource
{
public:
    enum Usage
    {
        WriteOnce,      // (default) CPU only fills the vertex buffer once, and 
never touches it again
        ReadOnly,       // CPU reads from the vertex buffer, which can never be 
rendered
        WriteOnly,      // CPU writes frequently to vertex buffer, but never rea
d data back
    };

    enum VertexComponent
    {
        Coord    = (1<<0),
        Normal   = (1<<1),
        Tangent  = (1<<2),
        Binormal = (1<<3),

    /// constructor
    nMesh2();
    /// destructor
    virtual ~nMesh2();
    /// unload mesh resource
    virtual void Unload();
    /// lock vertex buffer
    virtual float* LockVertices();
    /// unlock vertex buffer
    virtual void UnlockVertices();

******************************XML output****************************************

  <Class id="_4" name="nMesh2" context="_1" mangled="6nMesh2" location="f0:90" f
ile="f0" line="90" members="_560 _561 _562 _563 _564 _565 _566 _567 _568 _569 _5
70 _571 _572 _573 _574 _575 _576 _577 _578 _579 _580 _581 _582 _583 _584 _585 _5
86 _587 _588 _589 _590 _591 _592 _593 _594 _595 _596 _597 _598 _599 " bases="_19
1 "/>

..

  <Enumeration id="_571" name="Usage" context="_4" location="f0:93" file="f0" li
ne="93">
    <EnumValue name="WriteOnce" init="0"/>
    <EnumValue name="ReadOnly" init="1"/>
    <EnumValue name="WriteOnly" init="2"/>
  </Enumeration>

...
  <Enumeration id="_572" name="VertexComponent" context="_4" location="f0:100" f
ile="f0" line="100">
    <EnumValue name="Coord" init="1"/>
    <EnumValue name="Normal" init="2"/>
    <EnumValue name="Tangent" init="4"/>
    <EnumValue name="Binormal" init="8"/>
...
  </Enumeration>
...

  <Constructor id="_573" name="nMesh2" artificial="1" context="_4" mangled="_ZN6
nMesh2C1ERKS_ *INTERNAL* " location="f0:90" file="f0" line="90">
    <Argument name="_ctor_arg" type="_1296"/>
  </Constructor>
  <Constructor id="_574" name="nMesh2" context="_4" mangled="_ZN6nMesh2C1Ev *INT
ERNAL* " location="f0:115" file="f0" line="115" extern="1"/>
  <Destructor id="_575" name="nMesh2" virtual="1" context="_4" mangled="_ZN6nMes
h2D1Ev *INTERNAL* " location="f0:117" file="f0" line="117" extern="1">
  </Destructor>
  <Method id="_576" name="Unload" returns="_729" virtual="1" context="_4" mangle
d="_ZN6nMesh26UnloadEv" location="f0:119" file="f0" line="119" extern="1"/>
  <Method id="_577" name="LockVertices" returns="_833" virtual="1" context="_4" 
mangled="_ZN6nMesh212LockVerticesEv" location="f0:121" file="f0" line="121" exte
rn="1"/>
  <Method id="_578" name="UnlockVertices" returns="_729" virtual="1" context="_4
" mangled="_ZN6nMesh214UnlockVerticesEv" location="f0:123" file="f0" line="123" 
extern="1"/>



yaxx on hello world test, xml, dtd follows:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="yaxx.xsl"?><!DOCTYPE file SYSTEM "yyyaxx.dtd">
<yaxx:file xmlns:yaxx="urn:YAcc-Xml-eXtension">
<yaxx:external_definition>
<yaxx:function_definition>
<yaxx:declaration_specifiers>
<yaxx:type_specifier>
<yaxx:INT>int</yaxx:INT>
</yaxx:type_specifier>
</yaxx:declaration_specifiers>
<yaxx:declarator>
<yaxx:declarator2>
<yaxx:declarator2>
<yaxx:identifier>
<yaxx:IDENTIFIER>main</yaxx:IDENTIFIER>
</yaxx:identifier>
</yaxx:declarator2>
<yaxx:PUNCT_LPAR>(</yaxx:PUNCT_LPAR>
<yaxx:PUNCT_RPAR>)</yaxx:PUNCT_RPAR>
</yaxx:declarator2>
</yaxx:declarator>
<yaxx:function_body>
<yaxx:compound_statement>
<yaxx:PUNCT_LBRACE>{</yaxx:PUNCT_LBRACE>
<yaxx:statement_list>
<yaxx:statement>
<yaxx:jump_statement>
<yaxx:RETURN>return</yaxx:RETURN>
<yaxx:expr>
<yaxx:assignment_expr>
<yaxx:conditional_expr>
<yaxx:logical_or_expr>
<yaxx:logical_and_expr>
<yaxx:inclusive_or_expr>
<yaxx:exclusive_or_expr>
<yaxx:and_expr>
<yaxx:equality_expr>
<yaxx:relational_expr>
<yaxx:shift_expr>
<yaxx:additive_expr>
<yaxx:multiplicative_expr>
<yaxx:cast_expr>
<yaxx:unary_expr>
<yaxx:postfix_expr>
<yaxx:primary_expr>
<yaxx:PUNCT_LPAR>(</yaxx:PUNCT_LPAR>
<yaxx:expr>
<yaxx:assignment_expr>
<yaxx:conditional_expr>
<yaxx:logical_or_expr>
<yaxx:logical_and_expr>
<yaxx:inclusive_or_expr>
<yaxx:exclusive_or_expr>
<yaxx:and_expr>
<yaxx:equality_expr>
<yaxx:relational_expr>
<yaxx:shift_expr>
<yaxx:additive_expr>
<yaxx:multiplicative_expr>
<yaxx:cast_expr>
<yaxx:unary_expr>
<yaxx:postfix_expr>
<yaxx:postfix_expr>
<yaxx:primary_expr>
<yaxx:identifier>
<yaxx:IDENTIFIER>yyparse</yaxx:IDENTIFIER>
</yaxx:identifier>
</yaxx:primary_expr>
</yaxx:postfix_expr>
<yaxx:PUNCT_LPAR>(</yaxx:PUNCT_LPAR>
<yaxx:PUNCT_RPAR>)</yaxx:PUNCT_RPAR>
</yaxx:postfix_expr>
</yaxx:unary_expr>
</yaxx:cast_expr>
</yaxx:multiplicative_expr>
</yaxx:additive_expr>
</yaxx:shift_expr>
</yaxx:relational_expr>
</yaxx:equality_expr>
</yaxx:and_expr>
</yaxx:exclusive_or_expr>
</yaxx:inclusive_or_expr>
</yaxx:logical_and_expr>
</yaxx:logical_or_expr>
</yaxx:conditional_expr>
</yaxx:assignment_expr>
</yaxx:expr>
<yaxx:PUNCT_RPAR>)</yaxx:PUNCT_RPAR>
</yaxx:primary_expr>
</yaxx:postfix_expr>
</yaxx:unary_expr>
</yaxx:cast_expr>
</yaxx:multiplicative_expr>
</yaxx:additive_expr>
</yaxx:shift_expr>
</yaxx:relational_expr>
</yaxx:equality_expr>
</yaxx:and_expr>
</yaxx:exclusive_or_expr>
</yaxx:inclusive_or_expr>
</yaxx:logical_and_expr>
</yaxx:logical_or_expr>
</yaxx:conditional_expr>
</yaxx:assignment_expr>
</yaxx:expr>
<yaxx:PUNCT_SEMICOLON>;</yaxx:PUNCT_SEMICOLON>
</yaxx:jump_statement>
</yaxx:statement>
</yaxx:statement_list>
<yaxx:PUNCT_RBRACE>}</yaxx:PUNCT_RBRACE>
</yaxx:compound_statement>
</yaxx:function_body>
</yaxx:function_definition>
</yaxx:external_definition>
</yaxx:file>





dtd, hmm this doesn't seem to match much:


<!ELEMENT primary_expr (identifier | CONSTANT | STRING_LITERAL | (PUNCT_LPAR,expr,PUNCT_RPAR))>
<!ELEMENT postfix_expr (primary_expr | (postfix_expr,PUNCT_LBRACKET,expr,PUNCT_RBRACKET) | (postfix_expr,PUNCT_LPAR,PUNCT_RPAR) | (postfix_expr,PUNCT_LPAR,argument_expr_list,PUNCT_RPAR) | (postfix_expr,PUNCT_DOT,identifier) | (postfix_expr,PTR_OP,identifier) | (postfix_expr,INC_OP) | (postfix_expr,DEC_OP))>
<!ELEMENT argument_expr_list (assignment_expr | (argument_expr_list,PUNCT_COMMA,assignment_expr))>
<!ELEMENT unary_expr (postfix_expr | (INC_OP,unary_expr) | (DEC_OP,unary_expr) | (unary_operator,cast_expr) | (SIZEOF,unary_expr) | (SIZEOF,PUNCT_LPAR,type_name,PUNCT_RPAR))>
<!ELEMENT unary_operator (PUNCT_AMBLE | PUNCT_STAR | PUNCT_PLUS | PUNCT_MINUS | PUNCT_TILDE | PUNCT_EXCLAIM)>
<!ELEMENT cast_expr (unary_expr | (PUNCT_LPAR,type_name,PUNCT_RPAR,cast_expr))>
<!ELEMENT multiplicative_expr (cast_expr | (multiplicative_expr,PUNCT_STAR,cast_expr) | (multiplicative_expr,PUNCT_DIV,cast_expr) | (multiplicative_expr,PUNCT_PERCENT,cast_expr))>
<!ELEMENT additive_expr (multiplicative_expr | (additive_expr,PUNCT_PLUS,multiplicative_expr) | (additive_expr,PUNCT_MINUS,multiplicative_expr))>
<!ELEMENT shift_expr (additive_expr | (shift_expr,LEFT_OP,additive_expr) | (shift_expr,RIGHT_OP,additive_expr))>
<!ELEMENT relational_expr (shift_expr | (relational_expr,PUNCT_LT,shift_expr) | (relational_expr,PUNCT_GT,shift_expr) | (relational_expr,LE_OP,shift_expr) | (relational_expr,GE_OP,shift_expr))>
<!ELEMENT equality_expr (relational_expr | (equality_expr,EQ_OP,relational_expr) | (equality_expr,NE_OP,relational_expr))>
<!ELEMENT and_expr (equality_expr | (and_expr,PUNCT_AMBLE,equality_expr))>
<!ELEMENT exclusive_or_expr (and_expr | (exclusive_or_expr,PUNCT_CARET,and_expr))>
<!ELEMENT inclusive_or_expr (exclusive_or_expr | (inclusive_or_expr,PUNCT_OR,exclusive_or_expr))>
<!ELEMENT logical_and_expr (inclusive_or_expr | (logical_and_expr,AND_OP,inclusive_or_expr))>
<!ELEMENT logical_or_expr (logical_and_expr | (logical_or_expr,OR_OP,logical_and_expr))>
<!ELEMENT conditional_expr (logical_or_expr | (logical_or_expr,PUNCT_QUESTION,logical_or_expr,PUNCT_COLON,conditional_expr))>
<!ELEMENT assignment_expr (conditional_expr | (unary_expr,assignment_operator,assignment_expr))>
<!ELEMENT assignment_operator (PUNCT_EQUAL | MUL_ASSIGN | DIV_ASSIGN | MOD_ASSIGN | ADD_ASSIGN | SUB_ASSIGN | LEFT_ASSIGN | RIGHT_ASSIGN | AND_ASSIGN | XOR_ASSIGN | OR_ASSIGN)>
<!ELEMENT expr (assignment_expr | (expr,PUNCT_COMMA,assignment_expr))>
<!ELEMENT constant_expr (conditional_expr)>
<!ELEMENT declaration ((declaration_specifiers,PUNCT_SEMICOLON) | (declaration_specifiers,init_declarator_list,PUNCT_SEMICOLON))>
<!ELEMENT declaration_specifiers (storage_class_specifier | (storage_class_specifier,declaration_specifiers) | type_specifier | (type_specifier,declaration_specifiers))>
<!ELEMENT init_declarator_list (init_declarator | (init_declarator_list,PUNCT_COMMA,init_declarator))>
<!ELEMENT init_declarator (declarator | (declarator,PUNCT_EQUAL,initializer))>
<!ELEMENT storage_class_specifier (TYPEDEF | EXTERN | STATIC | AUTO | REGISTER)>
<!ELEMENT type_specifier (CHAR | SHORT | INT | LONG | SIGNED | UNSIGNED | FLOAT | DOUBLE | CONST | VOLATILE | VOID | struct_or_union_specifier | enum_specifier | TYPE_NAME)>
<!ELEMENT struct_or_union_specifier ((struct_or_union,identifier,PUNCT_LBRACE,struct_declaration_list,PUNCT_RBRACE) | (struct_or_union,PUNCT_LBRACE,struct_declaration_list,PUNCT_RBRACE))>
<!ELEMENT IDENTIFIER (#PCDATA)>
<!ELEMENT CONSTANT (#PCDATA)>
<!ELEMENT STRING_LITERAL (#PCDATA)>
<!ELEMENT SIZEOF (#PCDATA)>
<!ELEMENT PTR_OP (#PCDATA)>
<!ELEMENT INC_OP (#PCDATA)>
<!ELEMENT DEC_OP (#PCDATA)>
<!ELEMENT LEFT_OP (#PCDATA)>
<!ELEMENT RIGHT_OP (#PCDATA)>
<!ELEMENT LE_OP (#PCDATA)>
<!ELEMENT GE_OP (#PCDATA)>
<!ELEMENT EQ_OP (#PCDATA)>
<!ELEMENT NE_OP (#PCDATA)>
<!ELEMENT AND_OP (#PCDATA)>
<!ELEMENT OR_OP (#PCDATA)>
<!ELEMENT MUL_ASSIGN (#PCDATA)>
<!ELEMENT DIV_ASSIGN (#PCDATA)>
<!ELEMENT MOD_ASSIGN (#PCDATA)>
<!ELEMENT ADD_ASSIGN (#PCDATA)>
<!ELEMENT SUB_ASSIGN (#PCDATA)>
<!ELEMENT LEFT_ASSIGN (#PCDATA)>
<!ELEMENT RIGHT_ASSIGN (#PCDATA)>
<!ELEMENT AND_ASSIGN (#PCDATA)>
<!ELEMENT XOR_ASSIGN (#PCDATA)>
<!ELEMENT OR_ASSIGN (#PCDATA)>
<!ELEMENT TYPE_NAME (#PCDATA)>
<!ELEMENT TYPEDEF (#PCDATA)>
<!ELEMENT EXTERN (#PCDATA)>
<!ELEMENT STATIC (#PCDATA)>
<!ELEMENT AUTO (#PCDATA)>
<!ELEMENT REGISTER (#PCDATA)>
<!ELEMENT CHAR (#PCDATA)>
<!ELEMENT SHORT (#PCDATA)>
<!ELEMENT INT (#PCDATA)>
<!ELEMENT LONG (#PCDATA)>
<!ELEMENT SIGNED (#PCDATA)>
<!ELEMENT UNSIGNED (#PCDATA)>
<!ELEMENT FLOAT (#PCDATA)>
<!ELEMENT DOUBLE (#PCDATA)>
<!ELEMENT CONST (#PCDATA)>
<!ELEMENT VOLATILE (#PCDATA)>
<!ELEMENT VOID (#PCDATA)>
<!ELEMENT STRUCT (#PCDATA)>
<!ELEMENT UNION (#PCDATA)>
<!ELEMENT ENUM (#PCDATA)>
<!ELEMENT ELIPSIS (#PCDATA)>
<!ELEMENT RANGE (#PCDATA)>
<!ELEMENT CASE (#PCDATA)>
<!ELEMENT DEFAULT (#PCDATA)>
<!ELEMENT IF (#PCDATA)>
<!ELEMENT ELSE (#PCDATA)>
<!ELEMENT SWITCH (#PCDATA)>
<!ELEMENT WHILE (#PCDATA)>
<!ELEMENT DO (#PCDATA)>
<!ELEMENT FOR (#PCDATA)>
<!ELEMENT GOTO (#PCDATA)>
<!ELEMENT CONTINUE (#PCDATA)>
<!ELEMENT BREAK (#PCDATA)>
<!ELEMENT RETURN (#PCDATA)>
<!ELEMENT PUNCT_COLON (#PCDATA)>
<!ELEMENT PUNCT_SEMICOLON (#PCDATA)>
<!ELEMENT PUNCT_COMMA (#PCDATA)>
<!ELEMENT PUNCT_DOT (#PCDATA)>
<!ELEMENT PUNCT_EQUAL (#PCDATA)>
<!ELEMENT PUNCT_AMBLE (#PCDATA)>
<!ELEMENT PUNCT_STAR (#PCDATA)>
<!ELEMENT PUNCT_PLUS (#PCDATA)>
<!ELEMENT PUNCT_MINUS (#PCDATA)>
<!ELEMENT PUNCT_TILDE (#PCDATA)>
<!ELEMENT PUNCT_EXCLAIM (#PCDATA)>
<!ELEMENT PUNCT_QUESTION (#PCDATA)>
<!ELEMENT PUNCT_OR (#PCDATA)>
<!ELEMENT PUNCT_DIV (#PCDATA)>
<!ELEMENT PUNCT_PERCENT (#PCDATA)>
<!ELEMENT PUNCT_LT (#PCDATA)>
<!ELEMENT PUNCT_GT (#PCDATA)>
<!ELEMENT PUNCT_CARET (#PCDATA)>
<!ELEMENT PUNCT_LPAR (#PCDATA)>
<!ELEMENT PUNCT_RPAR (#PCDATA)>
<!ELEMENT PUNCT_LBRACKET (#PCDATA)>
<!ELEMENT PUNCT_RBRACKET (#PCDATA)>
<!ELEMENT PUNCT_LBRACE (#PCDATA)>
<!ELEMENT PUNCT_RBRACE (#PCDATA)>

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

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeff,

On Feb 28, 2005, at 10:39 PM, Jeff Henrikson wrote:

> Well, I see three possible paths.
>
...
>
> Any of the three solutions basically entail getting the output back to 
> a Cabs (frontc) similar representation.  It will be necessary to add a 
> named attributes for parent class, language and so on, but that would 
> be my basic strategy.
>
Since we're now discussing alternatives to Frontc, perhaps it would be 
worth looking at <http://www.cs.berkeley.edu/~smcpeak/elkhound> also. 
It includes a C and C++ grammar, and generates parsers in either C++ or 
O'Caml.

> Cheers,
>
>
> Jeff
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkIr5LIACgkQO3fYpochAqIfuQCg8k3vyKOoCBbr0WwSrDiLT0hD
FeIAoJ71ueb5rQ2kl2IPz5PNx2VWz9GL
=p5SM
-----END PGP SIGNATURE-----