> I would like to tinker with Cocoa bindings and try to move that > project forward.
> Where should I start from? I would like to take the route of > parsing Obj-C header files.
The swig manual states that they support experimentally Objective-C parsing. Swig is a wrapper generator with an OCaml backend. So this might be a starting point :-)
Regards, Jean-Marie
PS: I don't have any experience with swig myself, therefore I don't claim that it is really good. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)
> I would like to tinker with Cocoa bindings and try to move that > project forward.
> Where should I start from? I would like to take the route of > parsing Obj-C header files.
I agree that this is long overdue. A long time ago, Mike Hamburg, Jeff Henrikson, and I made noises about working on this, based on Mike's work on addressing the runtime side of it (he got so far as to have a somewhat under-performant but usable runtime library integrating O'Caml with the Objective C runtime based, IIRC, on Obj.magic) and Jeff pointed out that Frontc, the parser that he used in his Forklift FFI, had diverged from probably the best one for real- world use, which is embedded in CIL and intertwined in ways that make it a challenge to backport. Mike, Jeff, if you're reading this, is this a fair characterization of your efforts and thoughts?
In any case, I still believe that:
1) It's worth addressing whatever issues need addressing in Mike's work. 2) It's worth resolving what parser to use and, IMHO, how to evolve Forklift to support generating calls to and from Objective C via Mike's runtime work. 3) It's worth combining the two to provide the Forklift annotations to allow calling into and out of Cocoa on Mac OS X. 4) It's worth writing an FRP system for O'Caml a la Yampa for Haskell. 5) It's worth using said FRP system in conjunction with perhaps <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto- u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a truly cross-platform GUI environment for O'Caml.
I must be missing something but ... what does FRP have to do with Cocoa bindings?
On Jul 20, 2006, at 5:40 PM, Paul Snively wrote:
> 4) It's worth writing an FRP system for O'Caml a la Yampa for Haskell. > 5) It's worth using said FRP system in conjunction with perhaps > <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto- > u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a > truly cross-platform GUI environment for O'Caml.
On 7/20/06, Paul Snively <psniv...@mac.com> wrote:
> 4) It's worth writing an FRP system for O'Caml a la Yampa for Haskell.
FWIW The past couple weeks I've been working on an FRP system modeled after PLT Scheme's FrTime for O'Caml. I hope to release a preliminary version in a week or so.
> 5) It's worth using said FRP system in conjunction with perhaps > <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto- > u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a > truly cross-platform GUI environment for O'Caml.
This is my idea also. Along with the FRP core I've been developing a simple set of GUI widgets based on lablgtk2 that integrate with it (with the the intent of also writing Cocoa and Win32 bindings).
> On Jul 20, 2006, at 5:40 PM, Paul Snively wrote:
>> 4) It's worth writing an FRP system for O'Caml a la Yampa for >> Haskell. >> 5) It's worth using said FRP system in conjunction with perhaps >> <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto- >> u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a >> truly cross-platform GUI environment for O'Caml.
> 2) Provide O'Caml a nice GUI framework that doesn't suffer the > vagaries of the usual OO GUI frameworks.
Does LabGTK suffer from this?
I'm new to OCaml but I've got Haskell experience and I'm thinking of following the HOC (Haskell Cocoa bindings) approach to parsing header files. I previously got most of a Lisp Cocoa bridge done (for Allegro CL) and found the dynamic approach to be in a pain in the rear due to the high numbers of hidden structs and classes that don't appear in header files but can be discovered through the runtime.
FRP is a new acronym to me. Anyone care to enlighten me? Does it mean "Functional Reactive Programming"? Any recommendations on where to get up to speed in FRP?
-Corey
On 7/20/06, Paul Snively <psniv...@mac.com> wrote:
> On Jul 20, 2006, at 9:57 AM, Joel Reymont wrote:
> > I must be missing something but ... what does FRP have to do with > > Cocoa bindings?
> In and of itself, nothing; I just like the FRP approach to GUI > programming, so I see an opportunity to kill two birds with one stone:
> 1) Provide O'Caml a nice FRP framework. > 2) Provide O'Caml a nice GUI framework that doesn't suffer the > vagaries of the usual OO GUI frameworks.
> Best regards, > Paul
> > On Jul 20, 2006, at 5:40 PM, Paul Snively wrote:
> >> 4) It's worth writing an FRP system for O'Caml a la Yampa for > >> Haskell. > >> 5) It's worth using said FRP system in conjunction with perhaps > >> <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto- > >> u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a > >> truly cross-platform GUI environment for O'Caml.
> In and of itself, nothing; I just like the FRP approach to GUI > programming, so I see an opportunity to kill two birds with one stone:
> 1) Provide O'Caml a nice FRP framework.
At the risk of engaging in more than my fair share of self-promotion,
I should point out that the OCaml NAE I/O Reactor library I just released is an FRP framework. It's pretty spare at the moment and needs a lot of additions. Also, I didn't write it with graphical user interfaces in mind-- the goal was a good framework for single- threaded multiplexing network application servers. (The acronym "NAE" stands for 'Network Application Environment'.)
The Yampa framework doesn't strike me as appropriate for building a GUI. I suspect such a GUI toolkit would offer highly underwhelming performance characteristics. I could be wrong about that, and would welcome such a surprise, but that's what my unscientific guess tells me.
> 2) Provide O'Caml a nice GUI framework that doesn't suffer the > vagaries of the usual OO GUI frameworks.
For my own part, I plan to do all my GUI work in Cocoa with native Objective-C. A more useful addition to the OCaml HUMP, I argue, would be bindings for CoreData.
At some point, if no one else has done it first, I will get around to
doing it myself. Don't anybody hold their breath waiting for it, though... I have a lot of hobby projects these days, what with a day job and a 6-month old baby in the house.
