[fetter-devel] Re: CFFI progress

[Kenny Tilton]

James Bielman wrote:

>Kenny Tilton <ktilton at nyc.rr.com> writes:
>  
>
>>I see two concerns:
>>
>>- will every Lisp support CFFI with the necessary low-level ops
>>
>>- are the low-level ops exported / stable / reliable / supported?
>>
>>- will CFFI sometimes be less effective than the implementation FFI?
>>  For example, Franz indicates their native sockets package works
>>  better with their MP code, so in MP situations would run better than
>>  a generic solution using winsock or native BSD sockets via the FFI.
>>    
>>
>
>While I'm not so ambitious as to try to write some sort of CLRFI and
>get every CL vendor to implement it, I am trying to take a slightly
>longer-term view, and at least convince each vendor to make a core set
>of functionality available and documented/exported/etc.
>
>For example, the reason 'cffi-allegro.lisp' doesn't exist yet is
>because I want to get Franz's input on how best to implement the
>CFFI-SYS specification for their Lisp, as they do not export some of
>the pieces I need.
>
>(Unfortunately I have essentially no time to work on any of this for
>most of July, but it will get done eventually).
>

>>>In CFFI, I've pretty much thrown out the UFFI interface and written
>>>my own.  In particular, everything that can conceivably be a
>>>function is a function, in contrast to UFFI which consists almost
>>>entirely of macros (many of which can be confusing WRT what gets
>>>evaluated on which Lisp).
>>>
>>>      
>>>
>>Yep. I think KMR realizes this and would cure in UFFI2.
>>    
>>
>
>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.

>The compatibility layer was basically a for-fun afterthought I had,
>and if I can't make it work for the bulk of the UFFI-ized libraries
>out there, I'll probably scrap it.
>
Understood, and agreed. KMR himself agrees UFFI has run its course. 
Existing UFFI bindings will take no more than a day to transform to 
something newer, so let's not handcuff the next generation.

-- 
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