[fetter-devel] Re: CFFI progress

[Kenny Tilton]

Luis Oliveira wrote:

> Hello,
>
> So, here's my (well mostly James') list of ideas and todo items
> for CFFI:
>
>   -> Port to more implementations.
>   -> Callbacks.
>   -> Foreign globals. 

Sounds reasonable. I just never encountered that. This means, however, 
an autogenerated C DLL to create a C interface?

>
>   -> Pushing things like #+cffi/callbacks onto *features*.
>   -> FOREIGN-SLOT-VALUE: let it take multiple "indices" for directly
>      accessing structs inside structs, arrays inside structs, etc... 

Hmm, not appearing clearly in my mind's eye. But I get the drift/value 
if feasible.

>
>   -> Type-checking pointer interface. 

OK, interesting. I went the other way: one type-trusting interface, one 
autoconverting interface.

>
>   -> well.. and a high-level interface, like CLISP's :-)
>   -> Complete uffi-compat. 

Irrelevant, but see below.

>
>   -> Documentation.
>   -> More tests/examples.
>
> The uffi-compat thing is very interesting. We don't have to worry
> about backwards compatibility at all. CFFI has 0 users. Yet
> uffi-compat will allow automatic access to what has already been
> uffi-ized.

"automatic access" has practically zero value. We will not diverge from 
UFFI gratuitously, so if it was a good interface it will survive largely 
unchanged even with the new underpinnings. If it was a sucky interface, 
we /want/ to kill it. If the latter obtains, automatic access will not 
fly. If, however, the UFFI API survives largely intact, a set of UFFI 
bindings can be transformed in a few hours. This equals "practically 
zero value" for backward compatibility.

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