Thanks. Your explanation was very helpful.
--Jim
On Mon, 2002-03-18 at 06:12, Ole Rohne wrote:
> 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
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima