[fetter-devel] Quick CFFI update

[Kenny Tilton]

Luis Oliveira wrote:

> On 4/jul/2005, at 05:49, Kenny Tilton wrote:
>
>> What stops you from simply eyeballing the different Lisps to see if 
>> they have the necessary hooks?
>
>
> Ok, I will do this. 

CFFI seems from a distance to be something for the open source crowd. 
"commercial lisps" are left as an exercise. Is this because it was 
expected one would have to hack on the implementations? Or this may  be 
because of performance issues? ie, CMUCL needed a fix? I do not know. 
Anyway, any "universal" FFI has to handle popular commercial lisps. Of 
course we always have a hybrid approach as a fallback, and if CFFI 
solves a performance problem it belongs in the mix somewhere.

>
>
>
>> btw, Are all patches already determined to be necessary going to be 
>> accepted by the maintainers of the Lisp in question?
>
>
> Regarding SBCL, it *is* a bug, so I'm pretty sure it'll be accepted. 
> About clisp I'm not so sure as it's not a bug per se. Also, IIRC, 
> other lisps might have the same issue as clisp (having to specify with 
> library the var/function is in) so I guess I might have to add a way 
> to specify that anyway. I think James is just trying not to specify 
> that unless absolutely necessary. 

FYI: Lispworks needs the library specified, AllegroCL does not.

>
>
>
>> Basically it sounds like you are somehow confident this story will 
>> have a happy ending, and I get the feeling that even if not, not much 
>> time will have been lost, so I am shaking my head but not worried.
>>
>> How long /will/ this exercise take?
>
>
> Well, I guess the UFFI approach would be safer (and easier even), but 
> I feel this approach is better. I also have the feeling that with the 
> low-level operators cffi exports, it'll be easier to support C++ (for 
> Fetter too). (And James plans an Objective C bridge someday). 

Can you give a specific example? I am actually mentoring five projects 
this summer, so it helps if the issues can be laid out with specific 
cases, well explained. That might help your own thought processes as 
well. Nothing like having to explain something to someone else.

>
>
> But if you feel I'm wrong, please do say so! I'm certainly not very 
> experienced in these kinds of decisions.
>
I just do not see the advantage yet. You mentioned the 
implementation-specific code was in one source file per implementation. 
Nice (having seen UFFI-style conditionalized code) but nothing big.

Is the idea that we do an end run on the different implementations' 
incompatible high-level APIs by resolving differences at a lower-level, 
perhaps unsupported or even unavailable level? ie, UFFI creates a 
uniform macrofied API which expands into implementation FFIese, meaning 
one has to master the nuances of each high-level API and then struggle 
to find common ground. Whereas with CFFI at the lower level we have 
fewer places that can diverge (and no matter what the high-level API 
looks like, they are bound to support certain lowlevel capabilities)?

That may all be rubbish, but it is the /kind/ of argument that would 
justify starting more or less from scratch on a new universal FFI. ie, I 
for one look for the "why?" behind your "I feel this approach is better".

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