[cffi-devel] Re: [fetter-devel] Quick CFFI update

[Kenny Tilton]

James Bielman wrote:

>Kenny Tilton <ktilton at nyc.rr.com> writes:
>
>  
>
>>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.
>>    
>>
>
>It's true that it's easy for me to take the long-term view about
>supporting more Lisp implementations since CFFI already supports the
>implementations that I use (mostly, I do need a LispWorks port).
>
Assuming CFFI is the right way to go in the long run, the best thing to 
do for the immediate objective (universal FFI now not manana)  is take 
it as far as it will go and use native FFIs for Lisps that won't do 
CFFI. Then long run we have the luxury of time to jawbone non-CFFI-able 
Lisp maintainers.

>
>The reason the CFFI interface seems low-level compared to everything
>else is because it was designed while asking myself the question,
>"What is the minimum I need from a Lisp implementation in order to do
>useful things with its FFI?".  Performance is a goal, but it is not
>the primary goal.
>
OK, but why is "the minimum necessary" a Good Thing, aside from Occam's 
Razor and Einstein's "as simple as possible but no simpler"? My guess is 
that it is easier to invent one uniform high-level API atop a few 
low-level FFI capabilities than take a dozen high-level APIs and come up 
with a consistent super-high-level API. But no one is saying that except 
me. And CY. :)

>
>If an open source implementation has gaps in this support it's
>relatively easy for me to write patches to add that support, and they
>have a fair chance of getting applied.
>
>For commercial implementations there's little else to do but ask them
>nicely to support this API, perhaps dealing with reasons why it's not
>possible for them to do it, or they don't care, or maybe have
>technical reasons why the interface sucks.
>
I am anxious to get the Actual Landscape (in my mind's eye I see a 2D 
table, rows being Lisps, columns being needed support hooks for CFFI) to 
sharpen this discussion. I am also anxious, where gaps are found, for 
Luis to contact vendors/maintainers and get them to sign on to making 
necessary changes ASAP. Hopefully the prospect of being excoriated on 
c.l.l by Demon Kenny will bring cooperation. :)

In a sense, i guess what we are doing is a Pitamnesque substandard or a 
CLRFI, except instead of undertaking a process a few of are undertaking 
some coding. I always prefer coding, myself. :)

>
>So, I guess I took the easy way out by trying to implement things on
>the systems that I could be proactive about first, so when it comes
>time to beg others to implement them for me, I can say "but look, it
>works on these 5 other implementations..."
>
Man, I am /really/ curious about the Actual Landscape. Here is one gap: 
has the new killer CLisp FFI been ported to the Mac OS X version yet? 
Though in that case i would not consider this a gap in Hello-C/CFFI, 
since the old CLisp FFI was pretty weak and pretty much asked for 
trouble (such as being left out of portable FFI projects).

>
>Whether this is too long-term for your summer goals or not, I don't
>know.  I'm not really trying to convince anyone of anything ...
>
Totally understood, and no one is complaining about CFFI, which au 
contraire seems to be a hit. I hear even the Yobbos like it. :) But the 
project does have to produce a universal FFI by summer's end, so we are 
just trying to decide the best way.

Well, let me clarify. The line I am drawing is this: if a Lisp on a 
platform has a sufficiently powerful native FFI, Hello-C should be 
extended to that Lisp and platform. CLisp on OS X is an example of a 
Lisp/platform that can wait until the new CLisp FFI gets ported there, 
and indeed we should wait, unless the CLisp folks decide to support CFFI 
as a way of getting an FFI on that platform.

Come to think of it, that raises another question: does CFFI's 
high-level API rock as well as CLisp's new FFI on win32 and Unix? I am 
thinking of things like a lambda form being a Lisp callback from C.

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