[g-wrap] Changes needed by the "glueless" approach

[Andreas Rottmann]

[CCing Rob, as I don't know if he's on the new list already]

Hi!

I've already implemented part of the infrastructure that is needed for
calling functions without generating glue code for each function. Note
that this is what I refer to as glueless, not that it is implemented
in pure Scheme; there is still C code involved, although glue will be
generated for each type only, the glue for the functions/methods will
be generated at runtime.

So far I've built up an infrastructure for accessing type and function
information from C, as this is needed for runtime generation of
function glue code. So far I've got this information to be stored:
  
- For each type:
  * name (same as g-warp scheme name)
  * class name (possibly NULL)
  * dynamic flag (more on this later)
  * function pointers: c->scm, scm->c, c-destructor functions
  * procedure name
  * generic name (if this is a method of a generic function)

- For each function:
  * dynamic flag
  * proc void *: either normal wrapper (accepting SCM values) -- this 
    is what I call static wrapper -- or the pointer to the 
    to-be-wrapped C function in the dynamic case.
  * number of {required, optional} args + if we use the 
    extra args list (only relevant for the static wrappers)
  * number of arguments (only relevant for dynamic wrappers)
  * for each argument: a pointer to its type's info
    

So my basic idea for doing away with compiled [0] function wrappers is
to have a marshaller go thru the SCM args, convert them to C args
according to the arguments' types and call the C function via libffi
(or maybe ffcall or what it was called again). 

At this point, I wonder about what to do with typespecs -- those
describe additional properties of a type (e.g.  that it's caller-owned
for a char *) and can vary from argument to argument. It is clear that
we need typespecs at the marshaller level, too. This means we have to
convert them to a C bit field or something like that.

What I'm not clear about is wether we need those typspecs to be passed
to the type functions (c->scm, scm->c, c-destructor). I guess it
should be possible to have the code handling the typespecs only in the
marshaller, which then decides, for instance, wether to call the C
destructor for a char * we receive as a function return value. I'm
however quite unsure about this issue, since up to now, the scheme
equivalents (i.e. C-codegens, ccgs) of the aforementioned type
functions receive (and even use) the typespec. My impression reading
the code was, however, that the c->scm, scm->c and c-destructor ccgs
are only used internally by the type wrapper implementations and it
should be thus be possible to change their semantics so that they
don't require a typespec. Since changing their semantics is a pretty
important (I think) design decision I'd like to hear some thoughs from
Rob (and maybe others ;-)) on this topic.

[0] maybe "runtime" vs. "compiled" is better than "dynamic"
    vs. "static" -- opinions?

Regards and thanks for reading this thru, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.