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