Re: [Chicken-users] Constructing parameter lists in C: can I use FFI?

[Daniel B. Faken]

On Mon, 25 Jul 2005, felix winkelmann wrote:
> Since this is performance critical, I'd suggest that you implement the
> translation of C to Scheme types yourself (in C). If you are using OpenGL,
> the number of argument types you have to support is (relatively) small.

Yeah.. I actually "bit the bullet" & did this a few days ago.. I was just 
hoping there was someway to use Chicken's nice type-conversion facilities 
:).

> [..] Another method would be to store the arguments in
> a Scheme list allocated in static memory (this requires that you store
> only immediate or static data in that list), or in a once-allocated list
> that is GC-protected (via CHICKEN_new_gc_root()).

Interesting.. I had not considered that.

> Note that mixing callbacks and entry-points can be tricky: an entry-point
> leaves a continuation object on the temporary stack.
> Doing a callback after an entry-point returned will not work.
> A better idea might be to
> run CHICKEN_run once, with a Scheme toplevel that performs a
> ##sys#call-host and from then on only invoke Scheme via callbacks:
> 
[code elided]
> 
> This is somewhat, well, unorthodox, but might actually work... ;-)

AHA!  This is exactly what I was looking for, but didn't know existed -- 
some way to "enter the Scheme toplevel" without calling-back into C (which 
for me is verboten since my code "is just a C library")  Merci!

Also, this helps me understand why the FFI is so focussed on callbacks 
(instead of having equivalent facilities for entry points): entry points 
are just "default continuations" followed by ##sys#call-host, which 
temporarily interrupts (so to speak) the Scheme continuation to let C
take over for a while.
  (did I get that right?)
(now I also see what "if(!return_to_host)" in runtime.c:1079 is for..)

So..
  What do you think about getting rid of the entry-point API, storing
the continuation somewhere it can explicitly retrieved (if you want to 
exec some more top-level code), and letting callbacks always "just work" 
(after the initial setup).
  This seems to me much simpler, etc.  The current entry-point API calls 
could easily be translated to callbacks, if anyone needs them.

This is all from my primitive understanding of whats going on, though, so 
maybe there are some things that wouldn't work.


cheers,
Daniel Faken