Re: [gtk-list] Re: A type system for high-level interfaces

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:
> 
> On 24 Aug 1997, Marius Vollmer wrote:
> 
> > In fact, I'm thinking about writing one single but excessive generic
> > stub with libffi.  That stub would be able to call any function that
> > can be described in terms of the fundamental types just by giving it
> > the description at run-time.  You could link in a new widget at
> > run-time, read the descriptions of the exported functions and be ready
> > to go.  No stub generation and compilation.  It wouldn't be
> > particularily fast, but I doubt that you can spot the difference in
> > most cases.
> 
> I think that is overkill. When you are fighting the compiler that hard,
> you probably want to shift to some other plan of attack. If we need
> dynamic stubs that badly, we can always use some dynamic trampoline
> package (one was recently released for Perl) to create the assembly at
> runtime. The param[] mechanism is easier and more flexible in the long
> run, except (ironically) at the C coding layer, where the marshalling
> functions are needed.

libffi is something like a trampoline generator, but only for function
calls and it doesn't actually emit code.  Rather, it contains the
needed platform-dependent assembler magic to construct argument lists
on the stack.

But you are right, the `super stub' is almost silly.  I'm not really
serious about it.
 
> > The list of literals of enumeration would probably not dynamic but the
> > new ones could pop up at any time.  If that is a problem, we can make
> > the set of enumerations exported by Gtk static.

[Whoa, sorry for the many grammar bugs in that passage]
 
> Hmm. That brings up an interesting issue: dealing with addition widgets.
> There's no particular reason why the Perl code should only deal with Gtk
> widgets, assuming other ones are written to the same standards. That would
> mean additional enumeration types _would_ be nice. However, at this point,
> I think the technical considerations make it too much of an issue.

Could you elaborate on these technical issues?  Right now, I only see
problems with the performance, because my Scheme glue has to search
the list of enumeration literals for every call.

To explain, what I have in mind for enumerations: You could write this
code to create a toplevel window

    (gtk-window-new 'toplevel)

The 'toplevel argument is essentially a string that has to be strcmped
against all the literals of the GtkWindowType enumeration, at
run-time.  The stub for gtk-window-new knows that the argument is a
GtkWindowType enumeration and calls a Gtk function to obtain its type
id, much like gtk_object_get_type can be used to get the type id of
GtkObjects.  From that type id, all necessary information about the
enumeration can be obtained.

> Once we get to the point where _no_ C code is needed for the bindings
> (where everything can go through the equivalent of setv) then transparent
> support for new widgets is worth worrying about.

Agreed.  But we should allow these new widgets to bring new types with
them.  One obvious new type is the widget type itself, but other could
be enumerations, etc.  We probably can't allow new widgets to
introduce new fundamental types, like GdkPoint.
 
> That's another important issue: I don't want the Perl binding (or other
> bindings) to spend five seconds on startup just sitting their in an orgy
> of type queries. The more information that can be compiled in, the better. 

Yes, agreed.  Maybe the generation of (simple) stubs for new widgets
can be automated enough that it is feasible to do it during the normal
configuration/make of the new widget.
 
> > But -- unless I missing something -- writing rebust interface glue
> > requires being completely sure about the semantics of every little
> > function you want to wrap.  That usually requires reading the source
> > code and following the structures as they are passed around.  If you
> > have done that, my congratulations.
> 
> I had to read the source code of many functions, true, but there are many
> I haven't read, and many where it simply isn't easy to follow what exactly
> is done with a parameter. In any case, it should _not_ be necessary to
> read this stuff. Any decent documentation should sufficiently describe
> this sort of thing. (And I don't mean that as an attack on anyone who
> hasn't documented Gtk. Plenty of my own code isn't documented, and I'm not
> proud of it.) 

I hope that in the end my proposal turns into a precise description of
most of the types that appear in the Gtk API.  With them, you could
document the calling conventions of Gtk in a highly stylized manner.
That is both easier for the documentation author and for the user to
comprehend.

In fact, now that I've written the paragraph above, I see the things I
try to achieve with my posts here not so much as to change Gtk to my
own liking, but rather to document enough of Gtk in such a highly
stylized manner.  It should be so stylized that even a program can
understand it.

> > So please don't be afraid that I want to rewrite Gtk in Scheme or
> > something, far from it.
> 
> Great. :-)

To be completely honest, I'm currently tempted to rewrite gtkenums.h
into a more Lispy syntax.  But that probably brings more trouble than
it's worth.