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? This remembers me of the AMOP book which carefully distinguishes things possibly known at compile or macro-expansion time from the non-optimizable run-time path. It's design seems at odd which your approach of mixing both: the AMOP is very careful to separate the possibly known paths (depending on the type) from the unknown (depending on the value) and as a result, separates functions that operate on types only.
Regards, Jorg Hohle.
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
-
Hoehle, Joerg-Cyril -
James Bielman