[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