Re: CVS commit: uffi

> Just a short announce that I plan to add cormanlisp support 
> as soon as my schedule permits. probably mid of april.

Great -- glad to hear that. John Desoi is planning on adding
MCL support.

With then 5 platforms being supported, I think that the current
technique of placing all of the implementations in one file is
getting unwieldy. Further, since the interface is stabilizing,
I think it may soon be time to split each implementation into it's 
own set of source files.

Mid-april sounds like a good time to start. I hope that by that time the
interface will be stable.

> BTW: I agree that cstrings should be automatically translated.
> (If you wanted to say that)

String handling is problematic due to implementation variance. CMUCL
supports automatically translation to and from functions the best.
ACL handles it pretty well, but I've not found a way to prevent
a run-time warning about translating NIL values into NULL pointers.
LW doesn't handle automatic conversion at all.

Thus, for cross-platform support, UFFI users must call routines to
translate strings to and from functions. Unless, at some point,
I add a wrapper around a function definition that does string 
translation. For CMUCL, currently, with-cstring and 
convert-from-cstring doesn't do anything to the arguments.
So, I have a different set of routines (foreign-string) which always
allocates space and copies strings.

My thought is to make CMUCL use foreign-string type functionality in
it's function calls. Then, I can get rid of the set of 
routines that, for some implementations translation and for other 
implementations (CMUCL) do nothing.

I'm open to suggestions. The main design criteria is 1) cross-platform 
compatibility and 2) take advantage of implementation optimizations.
Whereever possible, I want to prevent someone from writing to an 
implementation-specific FFI because they thought UFFI added too much 
overhead or doesn't take advantage of implementation-specific 
optimizations.

Kevin