Re: [Chicken-users] MV in foreign-lambdas

[Peter Keller]

On Mon, Oct 07, 2002 at 11:12:29PM +0100, address@hidden wrote:
> What I've been doing for the GTK binding is:
> 
> static void listof(C_word argc, C_word self, C_word k, C_word param) {
>   C_word space[C_SIZEOF_PAIR];
>   C_word *a = space;
>   C_word p = C_pair(&a, param, C_SCHEME_END_OF_LIST);
>   C_kontinue(k, p);
> }
> 
> and then
> 
>   ((##core#primitive "listof") 'hello)   ==>   (hello)
> 
> This gets tedious fairly quickly. Plus of course adding in the
> required stack-depth checks (if you're allocating a *lot*) is extra
> make-work...

Out of curiosity, what prompted you to write the above type of code for
the GTK+ FFI? I've _never_ considered writing such code for the FFIs I'm
making and I want to know why. :)

> Not necessarily; so long as INOUT values are both in the parameter
> list and the result list, you're cool. You could then pass an
> immediate, and while it wouldn't get updated in place, the new value'd
> be passed back to you so you could update the location holding the
> immediate yourself.
> 
> ;; not a great example. oh well
> (define myadd1
>       (foreign-lambda void "add1" #:inout int))
> 
> (let ((x 42))
>       (set! x (add1 x)))

Uh, the above is scary code. If add1 returns int, then the (set! (add1 x))
looks _very_ strange to me.

> It kind of already does all the checking that's needed. It checks
> values on the way in, and unwraps them, and it takes the single
> resulting value on the way out, and wraps it appropriately. The only
> change would be to generalise it so it knows how to pass in C
> locations, too. Pseudo-code for how I imagine the wrappers to look

[snip]

> Hmm. That style may not generalise beyond simple types. Hmm. Perhaps
> allowing OUT/INOUT for foreign-lambda is a bad idea after all.

Hm... Maybe we are making things too complicated. :) There has to be an 
easier solution than either of us are thinking.

> Well I'd maybe be happy enough to allow multiple return values from a
> foreign-lambda*... this neatly sidesteps the issue of trying to guess
> the memory usage patterns of arbitrary C functions. You could have
> something like this to get the date out of a struct tm:

Yeah, but more often than not, you want to get data out of a c function,
and then put it back again after modifying it a little bit. We need to
be able to handle that symmetric case. I'm sure what felix has coded for
the FFI for chicken can do most of what we want, we just have to tease
it out of the API. I really think the conversion functions for foerign
types is awesome, and maybe if it is extended slighty(or maybe not even
that) it can become very useful to convert stuff between scheme and C.

-pete