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 _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
