[UFFI-Users] can UFFI be considered a compile-time transformation only?

Kevin Rosenberg kevin at rosenberg.net
Thu Sep 9 22:01:35 MDT 2004

Hoehle, Joerg-Cyril wrote:
> Can this go as fas as to conclude that UFFI can be viewed as a
> compile-time transformation only?

Yes, I think that's fair to say in general of UFFI. 
> That means that (nearly) all uses of UFFI macros have been
> transformed to native forms, and the UFFI package may not even be
> present at run-time (except maybe for find/load-foreign-library
> utilities). Is this how the efficiency design goal of UFFI is
> expected to be met?  It also means that all def-foreign-type
> declarations must have been processed by the compiler before using
> these types in other forms. UFFI should really document such
> expectations.

I agree with you. In general, UFFI disappears at compile time except
for a few utility functions, which include some optimized functions
called from convert-from-foreign-string for a few platforms.

> This obviously requires that all foreign types be known at compile-time. Either through forms that do not evaluate types (like def-foreign-type), or by limiting oneself to using quoted expressions like '(* foo) in forms (like def-type) that do -- which seems to be meeting Marco Baringer's expectations:

I'm not quite so sure of that. For example, Allegro allows run-time
evaluation of foreign types whereas other FFIs do not allow it. Given
that restriction across platforms, I think it's most sensible not to
promote UFFI as allowing run-time evaluation of types.  On the other
hand, if all platforms supported run-time type evaluation, then UFFI
should support that.

One example of a platform that doesn't allow run-time type evaluation
is deref-array on openmcl. The code
  (let* ((array-type (array-type type))
         (local-type (convert-from-uffi-type array-type :allocation))
         (element-size-in-bits (ccl::%foreign-type-or-record-size
	 local-type :bits)))
     (ccl::%foreign-type-or-record local-type)
     `(* ,i ,element-size-in-bits)
was provided by OpenMCL's author, Gary Byers. He told me there a
reason (outside of efficiency) that his code had to be have the type
determined at compile-time rather than run-time, but I don't recall
the exact reason provided.

Kevin Rosenberg
kevin at rosenberg.net

More information about the UFFI-Users mailing list