New UFFI design, CLISP FFI

Hi,

[sorry for the previous amount of quoting, I hit the send, not save button :-(]

Kevin Rosenberg wrote about the UFFI:
> I added a section on design priority to the manual. You can 
>   http://uffi.med-info.com/manual/x91.htm#AEN99
> I recommend reading this section and I request comments on 
> this section.

o the section is to short so as to comprehend what the design choices really mean in practice.
o "ensure-char-character" I did not find in the reference manual

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

(def-c-call-out gethostname
    (:arguments
     (name (c-ptr (c-array-max character #.MAXHOSTNAMELEN)) :out :alloca)
     (len size_t))
  (:return-type int))
The name will be (nth-value (gethostname MAXHOSTNAMELEN) 1).

An IDL (as in COM/CORBA) would declare something along:
  [out, is_size(len)] char[] name,
  [in]                size_t len
which is even more declarative and simplified.

I believe CLISP can be blamed for not providing a low-level view on function signatures. By low-level I mean one where neither :out modes nor lifetime are visible in the signature. The signature would map 1:1 from C.
This low-level API would be the one at which UFFI operates.

The result of a direct mapping to C (not possible with CLISP) is:
 + straight forward conversion of C declaration to Lisp routine, without reading the manual page and knowing what goes in and what goes out.
 - need to convert by hand to/from Lisp to foreign style strings (the C malediction)
 + flexibility, since parameter protocols can be really convoluted (esp. considering lifetime of objects and strings).
 - not suitable for COM/CORBA style signatures without rewriting: there, :out parameters are important.

So my belief is that UFFI can be blamed for not attempting to provide an abstract level of interfacing to the foreign world. It provides no more (and no less) than C level of interaction. I like to dream of a FFI-domain specific language (DSL) style of approach.

That doesn't mean that UFFI cannot be successful. I suppose you all know about "worse is better". UFFI works now with 3 implementations. Abstract level FFI may remain my dream for years.

Currently, I've serious doubts about whether a DSL for FFI is even possible without loss in flexibility or rather coverage of all situations (that is, the ability to cover even the weirdest parameter passing requirements, e.g. a char**name pointer to a buffer that you allocate and that the function will free at some time, but overwriting the pointer with one to another buffer on function return).
That's why a C-level portable FFI that UFFI implements is valuable now!

Regards,
	Jorg Hohle.
; who knows the FFI of AllegroCL, Lucid(!), CMUCL, CormanLisp, CLISP
; and designed an extra FFI for Amiga implementation of CLISP.