[fetter-devel] Re: CFFI progress

[Kenny Tilton]

Kenny Tilton wrote:

>
>
> James Bielman wrote:
>
>> It's hard though, because the host Lisp FFIs can vary wildy in how
>> they evaluate their arguments.  For example, to use OpenMCL's high
>> level FFI, almost everything has to be constant at macroexpansion
>> time.
>
> OK, and there were times I wanted UFFI macro args evaluated and they 
> were not, but not many.
>
>> UFFI even has to do some gross things like intern keyword
>> symbols at macroexpansion time for building structure references.
>>
>> I don't see that there's any way around these sorts of problems as
>> long as you are trying to paper over each Lisp's high-level
>> interface.
>>
> OK, but is this a fair summary?:
>
> Option A: The CFFI approach bypassing native Lisp FFIs. Works only on 
> some Lisps. (Which?) The other Lisps have to be persuaded to expose 
> and export some internals to support CFFI.
>
> Option B: Wrap native Lisp FFIs, accepting certain limitations such as 
> arguments not being evaluated. (Exactly which arguments to which FFI 
> entry points?) Persuade some Lisps to change their native FFIs to 
> evaluate certain arguments.
>
> With Option A, at summer's end only some Lisps are supported. 
> Optimization of Native FFIs is lost.
>
> With Option B, i think by summer's end we have a portable, truly 
> universal FFI, with the limitation that on some Lisps some arguments 
> are not evaluated. Optimization of native FFIs is retained. 

Btw, just to be clear, I love clean breaks with the past, which is why I 
kinda like the idea of a hybrid solution in which Lisps not ready for 
CFFI are supported via their native FFIs, the problem obviously being 
finding an api they all will support (perhaps, again, losing some power 
here and there where native FFI macros do not evaluate their arguments.

And if finding that common FFI becomes tedious, than it may well be wise 
to limit the summer project to doing a brilliant job extending CFFI to 
the utmost. What I would like to see is a list of which Lisps:

a. fully support CFFI with exported, supported hooks
b. support CFFI with unsupported hooks
c. can  support the CFFI API without compromise thx to native FFI
d. can support the CFFI API with exactly what compromises using native FFI

That landscape will inform the debate nicely, methinks.

-- 
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page