My 2c here: I don't think gobject introspection is going to help us that much. I have a few reasons:
1) Haskell is way different from the other languages that gobject introspection is aimed at (e.g. Python, Perl, etc.) Those are all procedural languages. Any binding generator is therefore going to necessarily expose the IO monad everywhere. There are many things that can safely be unsafePerformIO'd, that a generator won't be able to handle. 2) Hand-written bindings are better because a generator can never know what the *intent* of an API is. We can adapt a lot of the idioms used in the C libraries to Haskell idioms. For example, cairo's Render monad. Code generators can't do that. 3) Anyone that *really* needs stuff we don't provide can do one of three things (in decreasing order of preference): send us a patch, ask us nicely, or use the FFI directly. (This is what I think Axel was trying to get at.) Pete Marco Túlio Gontijo e Silva wrote: > Em Qua, 2008-07-09 às 22:34 +0200, Axel Simon escreveu: >> Hi Marco, > > Hi Axel. > >> On Jul 9, 2008, at 22:12, Marco Túlio Gontijo e Silva wrote: >> >>> 1) a completly auto-generated binding with full support to the GTK >>> family and >>> 2) a higher level library with this hand-written funcionality. >>> >>> I think this would be good for maintaining a full similar to C GTK >>> binding, and keeping gtk2hs specific features splited. The >>> documentation of the low level would not need much of corrections from >>> the C documentation, while the other one would have to be rewritten. >>> Don't you think it worths? >> I don't think that a "complete" wrapping around the C API is very >> useful as the challenge is mostly to determine what parameters mean. >> For instance, a pointer to a structure could be an input or an output >> and hence needs to be marshalled in, out or a ForeignPtr must be >> created. > > This is for sure a big problem, but gobject introspection is written to > avoid this kind of confusion. > >> An interface in the spirit of 1) is basically automatically >> generated by c2hs and hsc2hs which create foreign import declarations >> and marshalling functions from the more high-level (handwritten) >> Gtk2Hs source files. So in a sense, Gtk2Hs is already what you >> describe above! > > I don't agree with that. To use c2hs you need to have already written > the haskell code. The idea is to have a library without no haskell code > written at all, which is completly useful, in a sense that the > hand-written functions are only optional, and used only when it's much > better to have something more pratical available. > > I'll do some tests with gobject introspection and see how good can the > generated code get, and then you see if it's a good option to integrate > it with gtk2hs. > > Greetings. > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Gtk2hs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
