* OCaml && COCOA-Environment (Mac-OS-X/GUI)
@ 2005-02-05 0:02 Oliver Bandel
2005-02-05 16:37 ` [Caml-list] " Julien Roussel
0 siblings, 1 reply; 19+ messages in thread
From: Oliver Bandel @ 2005-02-05 0:02 UTC (permalink / raw)
To: caml-list
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)
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-05 0:02 OCaml && COCOA-Environment (Mac-OS-X/GUI) Oliver Bandel @ 2005-02-05 16:37 ` Julien Roussel 2005-02-05 19:51 ` Mike Hamburg 0 siblings, 1 reply; 19+ messages in thread From: Julien Roussel @ 2005-02-05 16:37 UTC (permalink / raw) To: Oliver Bandel; +Cc: caml-list, tipoix, ml-labo 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-05 16:37 ` [Caml-list] " Julien Roussel @ 2005-02-05 19:51 ` Mike Hamburg 2005-02-06 21:04 ` Paul Snively ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Mike Hamburg @ 2005-02-05 19:51 UTC (permalink / raw) To: Julien Roussel; +Cc: ml-labo, tipoix, caml-list, Oliver Bandel 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-05 19:51 ` Mike Hamburg @ 2005-02-06 21:04 ` Paul Snively 2005-02-07 2:24 ` Oliver Bandel 2005-02-17 7:12 ` Jeff Henrikson 2005-02-22 2:45 ` [Caml-list] " William D.Neumann 2005-02-22 10:54 ` Oliver Bandel 2 siblings, 2 replies; 19+ messages in thread From: Paul Snively @ 2005-02-06 21:04 UTC (permalink / raw) To: Mike Hamburg; +Cc: ml-labo, Julien Roussel, Oliver Bandel, caml-list, tipoix -----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----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 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 1 sibling, 1 reply; 19+ messages in thread From: Oliver Bandel @ 2005-02-07 2:24 UTC (permalink / raw) To: Paul Snively; +Cc: Mike Hamburg, ml-labo, Julien Roussel, caml-list, tipoix 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) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-07 2:24 ` Oliver Bandel @ 2005-02-09 19:41 ` Mike Hamburg 0 siblings, 0 replies; 19+ messages in thread From: Mike Hamburg @ 2005-02-09 19:41 UTC (permalink / raw) To: Oliver Bandel; +Cc: ml-labo, Paul Snively, Julien Roussel, caml-list, tipoix 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-06 21:04 ` Paul Snively 2005-02-07 2:24 ` Oliver Bandel @ 2005-02-17 7:12 ` Jeff Henrikson 2005-02-18 23:41 ` [Caml-list] " art yerkes 2005-02-25 2:03 ` Paul Snively 1 sibling, 2 replies; 19+ messages in thread From: Jeff Henrikson @ 2005-02-17 7:12 UTC (permalink / raw) To: Paul Snively Cc: Mike Hamburg, ml-labo, Julien Roussel, Oliver Bandel, caml-list, tipoix > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-17 7:12 ` Jeff Henrikson @ 2005-02-18 23:41 ` art yerkes 2005-02-25 2:03 ` Paul Snively 1 sibling, 0 replies; 19+ messages in thread From: art yerkes @ 2005-02-18 23:41 UTC (permalink / raw) To: Jeff Henrikson Cc: psnively, hamburg, ml-labo, julien.roussel, oliver, caml-list, tipoix 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-17 7:12 ` Jeff Henrikson 2005-02-18 23:41 ` [Caml-list] " art yerkes @ 2005-02-25 2:03 ` Paul Snively 2005-02-25 9:13 ` Oliver Bandel 2005-03-01 6:39 ` Jeff Henrikson 1 sibling, 2 replies; 19+ messages in thread From: Paul Snively @ 2005-02-25 2:03 UTC (permalink / raw) To: Jeff Henrikson Cc: Mike Hamburg, ml-labo, Julien Roussel, Oliver Bandel, caml-list, tipoix -----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----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-25 2:03 ` Paul Snively @ 2005-02-25 9:13 ` Oliver Bandel 2005-02-26 1:19 ` [Caml-list] " Sachin Shah 2005-03-01 6:39 ` Jeff Henrikson 1 sibling, 1 reply; 19+ messages in thread From: Oliver Bandel @ 2005-02-25 9:13 UTC (permalink / raw) To: caml-list What is Frontc and what is Cil - in a few words? TIA, Oliver ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-25 9:13 ` Oliver Bandel @ 2005-02-26 1:19 ` Sachin Shah 0 siblings, 0 replies; 19+ messages in thread From: Sachin Shah @ 2005-02-26 1:19 UTC (permalink / raw) To: Oliver Bandel; +Cc: caml-list 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-25 2:03 ` Paul Snively 2005-02-25 9:13 ` Oliver Bandel @ 2005-03-01 6:39 ` Jeff Henrikson 2005-03-07 5:20 ` Paul Snively 1 sibling, 1 reply; 19+ messages in thread From: Jeff Henrikson @ 2005-03-01 6:39 UTC (permalink / raw) To: Paul Snively Cc: Mike Hamburg, ml-labo, Julien Roussel, Oliver Bandel, caml-list, tipoix > >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)> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-03-01 6:39 ` Jeff Henrikson @ 2005-03-07 5:20 ` Paul Snively 0 siblings, 0 replies; 19+ messages in thread From: Paul Snively @ 2005-03-07 5:20 UTC (permalink / raw) To: Jeff Henrikson Cc: Mike Hamburg, ml-labo, Julien Roussel, Oliver Bandel, caml-list, tipoix -----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----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-05 19:51 ` Mike Hamburg 2005-02-06 21:04 ` Paul Snively @ 2005-02-22 2:45 ` William D.Neumann 2005-02-23 0:12 ` Jacques Garrigue 2005-02-22 10:54 ` Oliver Bandel 2 siblings, 1 reply; 19+ messages in thread From: William D.Neumann @ 2005-02-22 2:45 UTC (permalink / raw) To: Mike Hamburg; +Cc: caml-list 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-22 2:45 ` [Caml-list] " William D.Neumann @ 2005-02-23 0:12 ` Jacques Garrigue 2005-02-24 20:40 ` Paul Snively 0 siblings, 1 reply; 19+ messages in thread From: Jacques Garrigue @ 2005-02-23 0:12 UTC (permalink / raw) To: wneumann; +Cc: caml-list 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-23 0:12 ` Jacques Garrigue @ 2005-02-24 20:40 ` Paul Snively 2005-02-24 23:21 ` Oliver Bandel 0 siblings, 1 reply; 19+ messages in thread From: Paul Snively @ 2005-02-24 20:40 UTC (permalink / raw) To: Jacques Garrigue; +Cc: wneumann, caml-list -----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----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 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 0 siblings, 1 reply; 19+ messages in thread From: Oliver Bandel @ 2005-02-24 23:21 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Mostly OT: Apple and Language Adoption was Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-24 23:21 ` Oliver Bandel @ 2005-02-25 17:20 ` Paul Snively 0 siblings, 0 replies; 19+ messages in thread From: Paul Snively @ 2005-02-25 17:20 UTC (permalink / raw) To: Oliver Bandel; +Cc: caml-list -----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----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI) 2005-02-05 19:51 ` Mike Hamburg 2005-02-06 21:04 ` Paul Snively 2005-02-22 2:45 ` [Caml-list] " William D.Neumann @ 2005-02-22 10:54 ` Oliver Bandel 2 siblings, 0 replies; 19+ messages in thread From: Oliver Bandel @ 2005-02-22 10:54 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2005-03-07 5:21 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-02-05 0:02 OCaml && COCOA-Environment (Mac-OS-X/GUI) 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 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
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).