From: Marco T. G. e S. <ma...@ri...> - 2008-07-07 18:41:40
|
Hello, have you seen about this: http://blogs.gnome.org/johan/2007/11/30/future-of-gnome-language-bindings/ Do you think it may be used for generating all the haskell bindings to Gtk? The first thing I thought was that there are some things in gtk2hs which are not just bindings, but this may be still very useful. -- Marco Túlio Gontijo e Silva Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: ma...@ri... XMPP: ma...@ja... IRC: ma...@ir... Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil |
From: Axel S. <Axe...@en...> - 2008-07-08 08:16:15
|
On Mon, 2008-07-07 at 15:41 -0300, Marco Túlio Gontijo e Silva wrote: > Hello, > > have you seen about this: > > http://blogs.gnome.org/johan/2007/11/30/future-of-gnome-language-bindings/ > > Do you think it may be used for generating all the haskell bindings to > Gtk? > > The first thing I thought was that there are some things in gtk2hs which > are not just bindings, but this may be still very useful. > Duncan has built a very nice tool called apiGen that takes an XML description of the interfaces and creates Haskell functions. I think using introspection capabilities of GObjects was in the air once, so it might be an option. However, quite a bit of functionality of Gtk2Hs is hand-written and Haskell specific. Since we (I) started off writing everything by hand, we now have a tool that helps us write new things by hand by providing the definitions of most of the functions that we merge into the existing files. If we'd start from scratch, we might have a tool that does the merging itself, i.e. it would take an list of hand-written exceptional functions and generate files using these specifications and e.g. introspection for the off-the-mill functions. There are still a lot of exceptions and design decisions, e.g. whether to wrap a return value into a newtype or not. So, yes, we are aware of the design space. A. |
From: Marco T. G. e S. <ma...@ri...> - 2008-07-09 20:12:34
|
Em Ter, 2008-07-08 às 10:16 +0200, Axel Simon escreveu: > Duncan has built a very nice tool called apiGen that takes an XML > description of the interfaces and creates Haskell functions. I think > using introspection capabilities of GObjects was in the air once, so it > might be an option. apiGen is very nice, I haven't seen it yet. I does kind of the same thing that introspection would do, so I don't see much difference is using them, except that the intention of introspection is to serve as a source for bidings of all languages, and may have some facilities. > However, quite a bit of functionality of Gtk2Hs is hand-written and > Haskell specific. Since we (I) started off writing everything by hand, > we now have a tool that helps us write new things by hand by providing > the definitions of most of the functions that we merge into the existing > files. If we'd start from scratch, we might have a tool that does the > merging itself, i.e. it would take an list of hand-written exceptional > functions and generate files using these specifications and e.g. > introspection for the off-the-mill functions. > > There are still a lot of exceptions and design decisions, e.g. whether > to wrap a return value into a newtype or not. Maybe it would be more simple to have two layers: 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? Greetings. -- Marco Túlio Gontijo e Silva Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: ma...@ri... XMPP: ma...@ja... IRC: ma...@ir... Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil |
From: Axel S. <Axe...@en...> - 2008-07-09 20:34:29
|
Hi Marco, 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. 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! A. |
From: Marco T. G. e S. <ma...@ri...> - 2008-07-10 00:40:57
|
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. -- Marco Túlio Gontijo e Silva Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: ma...@ri... XMPP: ma...@ja... IRC: ma...@ir... Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil |
From: Axel S. <Axe...@en...> - 2008-07-10 08:08:41
|
On Wed, 2008-07-09 at 21:41 -0300, 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. It is true that this information is contained in the metadata. However, there are certain design decisions that we've made to make the library easier to use. That includes whether a type should be wrapped in a newtype definition and be opaque to the user, the omission of certain low-level APIs (some functions and signals in a widget are only useful to the widget itself), to an additional abstraction layer (e.g. UTF-8 to Unicode translation) or just plain re-implementation in Haskell (e.g. ModelView.*). It is very difficult (or impossible) to implement such layers on top of a low-level binding of the C functions without making the C functions themselves unusable (i.e. too low-level). We've had a long discussion about this before when the question was raised what a standard GUI API should look like. There was a consensus that one could distinguish between three API levels: low-level: minimal wrapper around the C functions mid-level: functions live in the IO Monad but the library makes certain things easy so that you can't shoot yourself in the foot (memory management); also some simple OO theme (set and get functions) high-level: combinators to connect or construct GUI objects, information flows via lazy channels or the like; examples are Fudgets. It's not clear that this approach works in the large as it looks like there are always tasks that cannot be done with a combinator library > > 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. We could use the introspection possibility in apiGen and I think Duncan has thought about that. > 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. I might be good if you think of how you can incorporate the data gleamed from introspection into apiGen. We could then think of ways to put the code that cannot be generated automatically into some sort of 'exception dictionary' and have apiGen generate all code before we build (rather than us doing a manual merge). One aspect that introspection cannot give us is versioning: We have gathered a lot of #ifdefs in our code and added comments to let people know what Gtk version they need to have. I don't think introspection can give you that. This could be an interesting long-term perspective. However, the build system of Gtk2Hs is already quite complicated. Generating all Haskell files automatically will make it even harder to Cabal to build it. Axel. |
From: Peter G. <pg...@gm...> - 2008-07-10 02:07:33
|
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. > |
From: Marco T. G. e S. <ma...@ri...> - 2008-07-10 13:18:02
|
Em Qua, 2008-07-09 às 22:07 -0400, Peter Gavin escreveu: > 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. These are very interesting points. This and some things Axel said in his e-mails made me think that haskell is a different case, and that providing just low-level bindings is not very useful... But it was nice talking about it. Thanks. -- Marco Túlio Gontijo e Silva Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: ma...@ri... XMPP: ma...@ja... IRC: ma...@ir... Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil |