Greetings! Just a quick note that I have locally a version which does all the macroexpansion up front in t1defun. Paradoxically, it increases compile time from 8:30m to 9:05m, mostly (I believe), due to its interference with certain type inferencing.
This is the so-called 'or-of-death' problem, whereby a simple form (unless (or a b) (foo)) in which both a and b are known to be nil when executing (foo), becomes: (if (not (let ((g a)) (if g g b))) (foo)) unraveling the latter to yield the same info as the former is something I'm thinking about at present. In any case, recursively-cmp-macroexpand works at least on all GCL and maxima code. There is a bit of an oddity in the current strategy, as the compiler macros in some cases will expand to different results depending on the local optimization setting. This is not passed in an env variable to the macroexpander, but rather in bindings to special variables governing the scope of the optimization declaration. I've never really understood how the environment is supposed to work in macroexpansion. Take care, -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
