Re: low-level of UFFI (was: CLISP support)

On Fri, Dec 13, 2002 at 06:29:48PM +0100, Hoehle, Joerg-Cyril wrote:
> Matthew Danish wrote:
> >UFFI does not currently support: foreign funcall of function pointers
> >(or function pointer types, I think), out and in-out function
> >arguments, casting, and callbacks.
> 
> CLISP has all of these. The problem for UFFI is probably how to define
> a common denominator.

Excellent.  I was under the impression that CLISP was reworking its FFI
at this time, but I guess that was wrong.  Defining a common denominator
isn't as bad as having no FFI in the first place =)  And Kevin has
already done a lot of the hard work.

> >Also worth thinking about is an interface that is flexible enough to
> >support run-time type and slot determination, but also be capable of
> >compile-time optimization where possible.
> I don't understand what you mean here. CLISP has FOREIGN-VARIABLE
> objects, and you can CAST at run-time, but this may not be what you're
> talking about.

In UFFI it's impossible to write something like:

(defun f (x type slot)
  (uffi:get-slot-value x type slot))

Because in many implementations UFFI:GET-SLOT-VALUE expands into a macro
which parses the type and slot at macro-expansion time.  I think they do
this for efficiency, but it would be nice to have both.

> >I'm hoping that I can collect all these features and formulate them
> >better, sometime, possibly to be the basis of UFFI2.
> 
> Me too, since I alyways claimed that UFFI as it currently stands is
> incredibly low-level (C level). :in/out parameters etc. would help,
> variable-sized buffer support also.

Well, I've been slowly adding macrology to my library that gives this
behavior on top of UFFI.  I think the latest version of UFFI supports
variable sized arrays too.

> Here's real code for CLISP: (def-c-call-out execvp (:arguments (file
> c-string) (argv (c-array-ptr c-string))) (:return-type int) (:name
> "execvp")) I'd like if somebody could show how to do this with UFFI,
> LW, ACL, CMUCL etc.

I don't think this example is too particularly hard, keeping in mind
that UFFI is low-level after all.

> So what I'm calling for is even more macrology :)

UFFI being low-level isn't a show-stopper; I've written higher-level
macros in terms of UFFI instead.

While UFFI itself is quite usable, and exists (this is key =), I think
there's lots of room for improvement even before getting to nice macro
tricks.

What I have in mind, though, is not a ``common denominator'' but rather
a specification for implementations to adapt to.  Then it would include
all features, not just those that implementations happen to support at
this time.  But this is a longer-term project...

-- 
; Matthew Danish <[email protected]>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."