[cffi-devel] Branch: New Type Translator Interface
James Bielman
jamesjb at jamesjb.com
Mon Jan 2 11:53:41 UTC 2006
On Mon, 2006-01-02 at 12:29 +0100, Hoehle, Joerg-Cyril wrote:
> James Bielman wrote:
> >I've done yet-another rewrite of the type translator
> >interface. It does
> >everything through generic functions at run-time, which allows us to
> >specialize on both the Lisp object being converted, and the
> >foreign type we are converting to.
>
> How does this interact with compiler macros and the wish for partial
> evaluation at compile-time?
If the (compiler-)macros that are responsible for calling these generic
functions are able to parse the type at macroexpansion-time (because it
is constant), they can avoid the generic function overhead if the type
is a built-in type (because the user is not allowed to define
translators on built-in types). I think this handles the most critical
path for optimization.
If the type must be evaluated, or it is a non-built-in type, there isn't
an easy way to avoid the call to the translator GF, even if it would end
up simply returning the value unchanged.
James
More information about the cffi-devel
mailing list