Subject: [clisp-list] CLISP FFI vs UFFI: an IMHO worse is better (lost?) battle

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Mar 20 02:37:05 2002

Hi,

Sam wrote:
> what I meant, loosely, was making sure that the CLISP FFI is better
> than the competition. :-)

I have currently very serious doubts about the possibility to achieve this goal. Here is what I just wrote to the UFFI mailing list.
UFFI is an FFI portability layer that currnetly works with AllegroCL, LispWorks and CMUCL.
http://uffi.med-info.com/manual/x91.htm

-------begin quote
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.

---

From: Sam Steingold <[email-masked]>
Date: Wed Mar 20 06:50:03 2002

Hi,
> * In message <[email-masked]>
> * On the subject of "[clisp-list] CLISP FFI vs UFFI: an IMHO worse is better (lost?) battle"
> * Sent on Wed, 20 Mar 2002 11:26:58 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> Sam wrote:
> I have currently very serious doubts about the possibility to achieve
> this goal. Here is what I just wrote to the UFFI mailing list.
> UFFI is an FFI portability layer that currnetly works with AllegroCL,
> LispWorks and CMUCL.  http://uffi.med-info.com/manual/x91.htm

If UFFI exports some high-level functionality based on the low-level
implementation-specific interfaces, then you can make CLISP export a
compatible functionality.

If UFFI export a low-level functionality, you can use it to implement
some high-level CLISP-style UUFFI (-: Unified UFFI :-) which will
support CLISP and whatever UFFI supports.

Additionally, you can improve CLISP FFI so suite your tastes.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
I don't like cats! -- Come on, you just don't know how to cook them!