On Thu, 16 Dec 2004 14:07:19 +0100, Juan Jose Garcia Ripoll <lisp@...> wrote:
> Well, in normal FFIs you explicitely destroy objects that you pass
> to the C world.
Not necessarily. IIRC Cormal Lisp can destroy these objects for you
and you don't have to do it manually. LispWorks, on the other hand,
provides macros for that - like WITH-DYNAMIC-FOREIGN-OBJECTS.
> I was not sure whether the same rule is expected to work with
Suppose I define a callback like this (in LW notation):
("square" :result-type :int)
(* arg-1 arg-1))
I expect the FFI to handle type conversions for me. But where else is
the problem? The incoming arguments are coming from the caller and I
don't have to worry about them being freed. The result is usually a
"native" Lisp type which'll be converted and put on the stack - no
problem either. If I (the user) explicitely allocate and return C
storage in my callback I have to take care of this, of course. But
that's not different from a C program, isn't it?
> As for passing a single C function, that can be a little bit more
> difficult, as one would really need to create specific C functions
> which are only intended for act as callbacks, as opposed to having a
> general callback function with some additional data that can
> dispatch depending on the data. The last option is for instance what
> the Boehm-Weiser garbage collector uses for many purposes.
If you want to be able to interface to existing libraries you have no
choice, I think, unless you are willing to write specific wrapper code