[UFFI-Users] get-slot-value and nested structures

[Hoehle, Joerg-Cyril]

Hi,

[rif]>I think my opinion is that UFFI is a case
[rif]> where if you ought to know the type symbolically when you write the
[rif]> code.
>
>That's mostly been the case since not all FFI's, openmcl stands out in
>my mind, evaluate types at run-time.

Maybe it's time for a few "HOWTO" UFFI rules (to be put into the manual)?

These would help people write UFFI code which they can hope works portably without them having to install half a dozen systems and test everywhere ("confidence").

o "Restrictions about the compilation environment similar to those for compiler other Common Lisp code apply when compiling UFFI forms."
E.g. DEF-TYPE must be known to the compiler (appear at top-level etc.) before processing a form referencing such a named type.

o "Using UFFI, all foreign types are to be considered statically known at compile-time."
Rationale: don't hinder those systems which compile to native code: they (typically?) expect foreign types to be known at compile time, so they can generate appropriate code (like a C compiler).

BTW, it's precisely the converse reason that makes CLISP evaluate types (e.g. ffi:cast, ffi:with-foreign-object): since it's all bytecode and thus a virtual machine, there's little benefit in having types set at some early time.
However, I've yet to see people take advantage of this: in general, types are known at compile time, and people use 'uint8 (i.e. quoted).

But for UFFI, I'd think macro evaluating types is superfluous ("get enough useful stuff done, don't get fancy").

I've heard nobody (but me) complain that acl:def-function, cmu:def-alien, uffi:define-foreign-function, FFI:DEF-CALL-OUT are macros which do not evaluate the arguments. It remembers me of CLOS' DEFCLASS macro vs. (A)MOP's ENSURE-CLASS function: most people only need classes known at compile time, DEFCLASS is enough/excellent for these situations.

o ...

Regards,
	Jorg Hohle.