Hi Daniel,
Sorry for the late reply, I'm on vacation.
Q1: no, you are not calling back into Scheme (you'd need define-external or something).
Q2: What it seems you are doing there is construct a compound object using the Chicken C-api. I try to avoid doing that.
Constructing Scheme objects in C is easy to get wrong. Everything is allocated on the stack so I think you have to use foreign-primitive to be safe, not foreign-lambda (I think). This may be an easier way:
You can define-external a simple scheme procedure that takes the three ints and returns list of them:
(define-external
(list_int3 (int a) (int b) (int c))
scheme-object
(list a b c))
;;C_word list_int3(int t0,int t1,int t2)
And use this to produce your compound object. However, keep in mind that the GC will move your objects around: Don't store lst anywhere in C between Scheme callbacks because it will be invalidated after gc. Note that this does violates the "don't use callbacks" advice!
Another trick which is useful to be aware of is using let-location. You can allocate objects in Scheme and pass them as pointers to your C procedures, which in turn can mutate them and we can multiple return values from Scheme side. I'm doing that here, for example:
My advice for beginners would be:
## don't allocate compound scheme objects in C because it is hard
but allocating "C objects" is usually not that hard though. if a library allocates a struct for you, go for it. and you can even use set-finalizer! on it.
## avoid Scheme callbacks if you can because it makes things hard
## whenever you can, allocate in Scheme and mutate in C
## box C structs in define-record's even if you feel it is slow
so you don't start mixing up types
Safety is always harder and more important that it seems. I've had so many cases where I have considered my bindings complete only to find I get the occational segfault - typically caused by the GC moving object around. But reproducing GC-related bugs can be hard.