Re: [gtk-list] Re: A description format for Gtk features

[Marius Vollmer <mvo zagadka ping de>]

Federico Mena <federico@nuclecu.unam.mx> writes:
> 
> >  Therefore I'd like to know how much extra burden you would tolerate
> >  for the sake of robust high-level bindings.
> 
> I think using a description file is fine.  If the thing can be made to
> generate C code from the description file automatically, it would
> rock.

Generating C code will be its main function in life, I think.  Not for
the Gtk sources but for the language bindings.

Oh, one point I forgot in my previous post:

What about documentation?  Would it make sense to put docstrings into
the description and then automatically generate parts of the .texi
files from them?

> >  Would you maintain such a description file?  Even if you don't use a
> >  high-level language yourself?
> 
> Definitely.  "I'd rather write programs to write programs than write
> programs" (Dick Sites) :-)
>
> >  A typical function description could look like:
> [example snipped]
> 
> I have slowly (read, *slowly*) been working on a C boilerplate code
> generator for creating new Gtk classes, in Scheme.  I have been going
> slowly because string processing in Scheme is not that nice, and I
> have done some things the hard way just to practice my Scheme :-)  

I don't think that we would have to do much string processing.  The
parsing is taken care of by the reader and the hairy C output can be
done with `format'.  The program would mainly slosh around symbols and
lists.

> The idea is to automatically generate most of the `standard' code
> required to make a new Gtk class (header file, class initialization
> code, signal marshallers, etc.).  My current definition file syntax
> looks like this:
> 
> (class-from 'GtkHBox
> 	    'GtkToolbar
> 	    (overrides-signal "add")
> 	    (new-signal "foo"
> 			'(GTK-RUN-FIRST GTK-RUN-NO-RECURSE)
> 			'(GTK-ARG-NONE "void")
> 			'((GTK-ARG-POINTER "GtkButton *" "button")))
> 	    (new-signal "bar"
> 			'(GTK-RUN-LAST)
> 			'(GTK-ARG-INT "gint")
> 			'((GTK-ARG-POINTER "GtkButton *" "button")
> 			  (GTK-ARG-LONG "glong" "squish"))))

[What are all the quotes doing there?  Looks more like a function call
 and not syntax.]
 
> I'm not yet finished with the code generator, so it's likely that some
> of that syntax will change.  But the point is that it *is* convenient
> to generate C code from the description file.  I think this thingy
> could be nicely integrated with your own idea, and a lot of the grunt
> work of making Gtk classes and language bindings would simply go away.

Yes, it could certainly make good use of the type descriptions.  It
can also be a type description itself, but we should keep interface
and implementation separat.

Right now, Gtk object descriptions simply state their ancestor:

    (define-object GtkToolbar (GtkHBox))

But that can be extended to include slots and signals:

    (define-object GtkToolbar (GtkHBox)
      (signal none foo (GtkButton button))
      (signal int bar (GtkButton button) (long squish)))

Taking this approach to the extreme, we would get some kind of "C with
Scheme syntax".  Such things already exist, like Aubrey Jaffars
"schlep", because some people can't stand coding in C any longer after
having been exposed to Scheme or Lisp for some time.

I like that idea and I'm quite certain that a Lispy syntax for the
description file is a good start for that.

But the Gtk sources that I would like to generate from the description
file are only some tables that are used to initialize the run-time
system.