A description format for Gtk features

[Marius Vollmer <mvo zagadka ping de>]

Hi,

I'm still busy on the general Gtk high-level language binding issues

    http://www-nt.e-technik.uni-dortmund.de/m_mvo/types.html

and would like to design a file format with which the exported
features of Gtk can be described in great detail.

The individual language bindings would use such a file to automate
most of the glue generation and would thus be able to pick up
additions to Gtk very quickly and confidently.

Idealy, as soon as someone develops a new widget for Gtk or adds some
other stuff to it, he should describe the new features in the special
format.  Thus, this file would not only be of interest to the inner
circle of high-level language users, but also to the regular Gtk
developer.

Therefore I'd like to know how much extra burden you would tolerate
for the sake of robust high-level bindings.

Would you maintain such a description file?  Even if you don't use a
high-level language yourself?

Would it be acceptable if the description file would be the definitive
place for some features (like enums)?  That is, if you want to change
the definition of the enumeration, you wuld have to do it in the
description file.

Would it be feasible to generate (parts of) the description file from
the C sources?

Would it be feasible to generate some C sources from the description
file? (will not happen during normal install of course)


What precise format should we use for the descriptions?

Not surprisingly, I propose using LISP syntax (just ask if you don't
know what that is).  That's what I know and where I am confident that
it can take us wherever we want to go today (tm).

A typical function description could look like:

    (define-func gtk_table_attach
      none                              ; return type
      (GtkTable table)                  ; first param
      (GtkWidget child)                 ; second
      (int left_attach)                 ; etc.
      (int right_attach)
      (int top_attach)
      (int bottom_attach)
      (GtkAttachOptions xoptions (= (expand fill)))  ; default value
      (GtkAttachOptions yoptions (= (expand fill)))
      (int xpadding (= 0))
      (int ypadding (= 0)))

The used types (GtkTable, GtkAttachOption) would have been defined
earlier in the file.

Of course, some form of LISP or Scheme interpreter is the natural
choice for interpreting this format.  I don't think we can expect
every Gtk developer to install Guile or some other Scheme.  But I hope
that almost everyone will have an Emacs handy.  Emacs Lisp is well
suited for this processing.  Using Emacs in batch mode is not at all
slow:

    % time -p emacs -no-init-file --no-site-file --batch --eval '(message "Hi!")'
    Hi!
    real 0.14
    user 0.03
    sys 0.02

What about Perl?  Can it work with the above syntax?  How would a more Perl
rendition look like?

As the last ressort, we could write a simple C program to do the
processing.  Maybe we can lift enough code from GCCs RTL processing
tools to make this trivial.

What do you think?