[Ecls-list] Announcement: RDNZL - a .NET bridge for CL

[Edi Weitz]

On Thu, 16 Dec 2004 14:07:19 +0100, Juan Jose Garcia Ripoll <lisp at arrakis.es> 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
> callbacks.

Suppose I define a callback like this (in LW notation):

  (fli:define-foreign-callable 
      ("square" :result-type :int)
      ((arg-1 :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
in C.

Cheers,
Edi.