Re: New UFFI design, CLISP FFI

> o the section is to short so as to comprehend what the design choices really mean in practice.

That's true, it doesn't state the exact consequences. I can put an example
to make it more clear. But, in general, the meaning is the UFFI programmer
will almost certainly need more code than if they used just their native
FFI, but will be rewarded by code that is portable and is as efficient as
possible.

> o "ensure-char-character" I did not find in the reference manual

Yes, sorry about that. I haven't put ensure-char-[character|integer] in
the manual because I'm not sure that I want to keep them. I'm looking for
a way to keep them from being necessary, but still enable open-code
compilation on Allegro and CMUCL.  Right now, LW is the "odd man" that
returns a char when dereferencing a (* :char). I believe that
derefercening a (* :char) should return the same type on all UFFI
platforms. ensure-char-* is an unpleasant hack, but appealing to enable
open-code compilation.

> o My greatest problem so far is that the UFFI is completely at odd with
> the CLISP FFI. I don't believe this can be blamed on one or the other
> (CLISP or UFFI).

If possible, I'd like to include CLISP as a supported platform. Right now,
there are volunteers for Corman and MCL ports. UFFI started as a lowest
common denominator solution. Although the interface is firming up and is
becoming more focused on efficiency, I'm willing to change it to support
CLISP, an important implementation. 

I'd like to see the interface become stable as soon as possible so UFFI
users can code for their libraries and not have to keep changing their
code to handle changes in the interface. But, I'm willing to change the 
interface to support the Corman and MCL ports.

> CLISP provides a sophisticated view on functions and parameter passing.
> It's not dissimilar to CMUCL's def-alien-routine and its :in-out
> parameter.

I've learned a fair amount about CMUCL, but am still learning. To support
implementations such as ACL and LW which don't have :out and :in-out
parameters, UFFI users have to use a less abstracted view. To support
:in-out, for example, I've require UFFI users to declare pointers to
objects, store their values in the pointers, call the function,
dereference the pointers, and then free the memory pointed to. I've taken
a quick look at the CLISP documentation this morning. Do you think CLISP
can work in this model?

As you stated, there are places for both models. The high-level :in-out
and the low-level approach as above. For implementations that don't have
automated :in-out procedures, a wrapper can be written around the function
call to handle this. I believe that is what CMUCL does. I'm not opposed to
having both a high-level and low-level interface. Perhaps adding
def-function-in-out declaration that allows :in/:out keywords and writes
suitable wrappers where necessary.

Having both methods may allow for both a simple user-interface where
applicable, and also a lower level interface to handle the complex
(nightmarish?) interfac example you provided.

If you are interested in working together to help support CLISP, perhaps 
you can join the uffi-devel mail list and we can move the conversation, 
and possible collaborative efforts, over there.

Thanks again for your insightful comments.

Kevin