>> Are you saying that AFFI is more low-level?
>> Maybe it would be easier to support UFFI with AFFI?
>I think that the AFFI code might be useful for the one who=20
>implements UFFI support.
I don't know (haven't checked clisp-devel archives recently) why the =
AFFI subject appeared. My opinion (claim) is that the CLISP FFI =
currently has most of what's needed for UFFI. Few things are missing =
(e.g. extract UTF/xyz string from/to address). I wrote an e-mail to =
this effect long ago in the UFFI-users mailing list. I don't know how =
AFFI would help the FFI.
What's missing is somebody who has time and understands enough of Lisp =
macros and U/FFI to be able to map one to the other.
It's true that the AFFI is much more lower-level than the FFI. However, =
using C-POINTER you can work at the same level with the FFI.
Like with CMUCL, you don't need the sophistication of :in/out =
parameters and modes. You can roll your own code, using pointers and =
memory management. That's what UFFI code does.
That's why I claimed several times in clisp-list and uffi-users that =
the current UFFI is low-level. I stand by my claim.
CLISP's FFI is much more declarative. But this is mostly a matter of =
The one point IMHO that's open w.r.t. UFFI->FFI is whether to hold UFFI =
pointers as FOREIGN-ADDRESS (untyped) or as FOREIGN-VARIABLE (typed =
pointers). The dereferencing code recently(?) added to UFFI needs =
FOREIGN-VARIABLE (for SLOT/DEREF etc.), while the typical call-out code =
is just happy with C-POINTER.
FOREIGN-VARIABLE, CAST etc. have extremely high (run-time) overhead in =
CLISP and should be used judiciously, whereas on other implementations, =
they usually compile to no-op or single-machine unstructions. I =
wouldn't want a top-level design decision provide food for "CLISP is =
slow" claims, when it can be avoided.
>After UFFI support is there, AFFI can probably be removed.
I don't see any relationship. What? Why?
It's true that UFFI could easily be build on top of AFFI, but that it =
because it's so simple and low-level, therefore it is amenable to =
everything (but callbacks). I already talked abour what I called =
abstraction inversion. FFI needed some low-level entry points. I =
provided some and I believe they are mostly sufficient. BTW, part of =
the AFFI design is incompatible with callbacks and concurrent GC, =
because it passes pointers to Lisp array objects and strings, which =
could move away.