[fetter-devel] ECL

[Juan Jose Garcia Ripoll]

Luis Oliveira wrote:

> UFFI tries to normalize/wrap/etc the FFI's of the various lisps. CFFI 
> on the other hand requests a few low-level operators from the lisp and 
> implements (or will implement) a FFI on top of that, bypassing the 
> lisp's FFI. For example, on SBCL CFFI doesn't use sb-alien, it uses 
> system-area-pointer's directly. I like this approach.
> I'm of course very interested in your views regarding the CFFI 
> approach vs. UFFI approach and FFI's in general.

Well, right now I have only two thoughts because I did not have much 
time to think about it, but they are:

1) Your handling of pointers is like the low-level layer we have for 
implementing UFFI. ECL has an object type which is called "foreign", 
which is basically a pointer to some memory. It may have been allocated 
by ECL or not. These objects are more than just SBCL's system areal 
pointers because they are not plain integers: they are a structure with 
a pointer, the size of the pointed area if known and a flag for the 
garbage collector.

All other primitives, such as foreign type sizes and alignments are 
there, too, since our interface for accessing structures and other C 
objects is built almost entirely in lisp. Furthermore, we also have 
primitives for storing/retreiving typed objects from pointers, although 
not the vectorized versions.

2) I have seen you have a single primitive, "%foreing-function-call", 
which can call a pointer with any number of types. Even though this may 
be implementable even in C (with a type cast), I do not very much like 
the idea. Personally I prefer wrappers. The reason is that, unlike other 
lisps, ECL can link its code against that of the C libraries. Currently, 
there is redundancy because we use not only the type declarations 
provided by the user in the FFI, but also those of the C headers of the 
code we are to link against. This means the C compiler can double-check 
the declarations made by the lisper and ensure everything will go right.

Juanjo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jlr.vcf
Type: text/x-vcard
Size: 389 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/fetter-devel/attachments/20050630/de9d5e09/attachment.vcf>