Re: GSoC proposal: gtk+ bindings for prolog



On Tue, 01 Apr 2008 12:32:02 -0500
Yevgen Muntyan <muntyan tamu edu> wrote:

> Jean-Yves Lefort wrote:
> > On Mon, 31 Mar 2008 22:52:09 +0200
> > Ben Torfs <bentorfs gmail com> wrote:
> >
> >   
> >> As a fan of both the prolog programming language and the GTK+ toolkit
> >> (as a user), I was wondering why the GTK page makes no mention of any
> >> prolog bindings. For those of you that are unfamiliar: prolog is a
> >> declarative language (like haskell, but very different in the way it
> >> works). Until now, it has mostly been used as a research tool in
> >> artificial intelligence (theorem proving, knowledge representation,
> >> etc.) However, I believe it has a lot of potential to be used for
> >> desktop applications too. Haskell too, for example, has also proven to
> >> be a success for end-user applications (gtk+ bindings exist). I think
> >> prolog is just a breeze to program in, and I would love to push it
> >> further! Specifically, by implementing GTK+ bindings for this language
> >> myself, as a Google Summer of Code project. Implementing all functions
> >> would probably be too much work for a 3-month project, but it could
> >> certainly deliver a basic subset, as a basis for myself and other
> >> developers to continue working on later.
> >>     
> >
> > It should take much less than 3 months. I've implemented exhaustive
> > GTK+ bindings for a language I'm designing in a couple of days.
> 
> Then your bindings most likely really really suck.

Ignorance or provocation? Whichever.

> >  The
> > internal API representation suitable for use by a generator program
> > can be automatically obtained:
> >
> > 	- for types and methods, by parsing the C headers
> >   
> 
> You'll get incomplete information which is far from enough.

The information is mostly complete. The generator can automatically
handle methods which involve fundamental types (gboolean, gint, ...),
GLib enum and flags types, and GObject-derived types. Such methods
represent a vast majority of the GTK+ API.

For other methods, it emits a warning, for instance "ignoring method
gtk_list_store_append(): unhandled parameter type GtkTreeIter*". I
then manually add the needed information to a configuration file.

By the way, in case some GTK+ developer is reading: it would have been
nice if GLib/GTK+ had offered a way to obtain type and method
information without having to hack up a .h parser, eg:

	GType *gtk_get_types (int *num_types);

	GMethodInfo *g_type_get_methods (GType type, int *num_methods);

It seems like a natural continuation of the reflection facilities
already present in GLib.

-- 
Jean-Yves Lefort <jylefort brutele be>

Attachment: pgpKG7AnklzHS.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]