James Amundson writes:
> I wish I understood all this issues involved in this problem better.
> Everything you say makes sense. I still don't understand why the old
> problem with MABS didn't seem to affect, e.g., MSQRT.
Now, if you *really* want to know, consider the following difference
between abs and sqrt:
(C1) abs(z);
(D1) ABS(z)
:lisp $d1 => ((MABS SIMP) $z)
(C2) sqrt(z);
(D2) SQRT(z)
:lisp $d2 => ((MEXPT SIMP) $z ((RAT SIMP) 1 2))
That is, sqrt(z) is immediately rewritten in a form that does not
involve MSQRT, so defining MSQRT as a macro never gets a chance to
confuse the simplifier (or whatever gets confused) by (DEFMACRO MABS
...) => (FBOUNDP 'MABS) -> T
> I believe you are right that we should have separate compile and
> load/save image stages.
I'm not sure I really wanted to argue for separate compile/save
stages, I see that as a pretty gross workaround for a deficiency in
CMUCL's (eval-when (compile) (defmacro ...))
I tested the new build procedure (still not separating compile/save)
with CMUCL 18d-pre on sparc and I'm happy to report that I don't get
the storm of errors expected. I think you know about the remaining
errors already:
Error(s) found in rtest12.mac: (error break)
Error(s) found in rtest14.mac: (error break)
Regards, Ole