Dr. Willis and I were attempting to make a potential post-normal-maxima
evaluation setup which checked whether inputs were functions or not.
We since concluded that since this is not a feature which should see
casual use, we could assume the programmer had checked the appropriate
documentation (or should have before resorting to this method). So it
is no longer necessary that this work, but I would still like to
understand a very odd behavior I have observed.
The function to add a function name to the list used by the
postevaluation routine is defined as follows:
(defun $addtofinalevallist (f)
;; Function to add function names to finalevallist
(cond
((mfboundp f)
(push f finalevallist))
(t (merror "Argument to 'addtofinalevallist' must be a
function"))))
When an attempt is made to use this function, say
addtofinalevallist(f1); the result is something along the lines of:
(%i13) addtofinalevallist(f1);
Maxima encountered a Lisp error:
The value $F1 is not of type LIST.
Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.
(%i14)
But a test shows that f1 was in fact added to the list and is used
properly.
If the function is redefined as follows:
(defun $addtofinalevallist (f)
;; Function to add function names to finalevallist
(cond
((mfboundp f)
(push f finalevallist)
(format t "finalevallist now contains ~S ~%" finalevallist))
(t (merror "Argument to 'addtofinalevallist' must be a
function"))))
the following occurs:
Maxima 5.9.1.1cvs http://maxima.sourceforge.net
Using Lisp SBCL 0.8.20
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) f1(x):=x^2;
2
(%o1) f1(x) := x
(%i2) addtofinalevallist(f1);
finalevallist now contains ($F1)
2
(%o2) false
(%i3) x;
2
(%o3) x
(%i4) x^2;
4
(%o4) x
(%i5) f2(x):=exp(x);
2
(%o5) (f2(x) := exp(x))
(%i6) a;
2
(%o6) a
(%i7) addtofinalevallist(f2);
finalevallist now contains ($F2 $F1)
2 false
(%o7) %e
(%i8) a;
2 a
(%o8) %e
(%i9) f3(x):=integrate(x,a);
2 f3(x) := integrate(x, a)
(%o9) %e
(%i10) addtofinalevallist(f3)$
finalevallist now contains ($F3 $F2 $F1)
(%i11) a;
2
a
(%o11) %e
(of course, these functions are totally inappropriate for this usage,
but they serve as tests.)
The lisp error has mysteriously vanished. Why??? What difference does
that format statement make? Why is lisp upset with the original
definition?
Any insight appreciated.
Thanks,
CY
This is the complete change set to macsys.lisp, as of now. (Dr. Willis
came up with the toplevel-macsyma-eval idea initially - all I have done
is tweak it.)
;; there is absoletely no need to catch errors here, because
;; they are caught by the macsyma-listener window process on
;; the lisp machine, or by setting the single toplevel process in
Maclisp. -gjc
;(defmacro toplevel-macsyma-eval (x) `(meval* ,x))
; Instead of the macro definition above, we will try a functional
; definition
;; Define the finaleval list
(defmvar finalevallist '())
(defun $addtofinalevallist (f)
;; Function to add function names to finalevallist
(cond
((mfboundp f)
(push f finalevallist)
(format t "finalevallist now contains ~S ~%" finalevallist))
(t (merror "Argument to 'addtofinalevallist' must be a
function"))))
(defun $removefinalevallist (f)
;; Function to remove function names from finalevallist
(delete f finalevallist))
(defun $showfinalevallist (f)
;; Function to remove function names from finalevallist
(format t "finalevallist contains ~S ~%" finalevallist))
(defun toplevel-macsyma-eval (x)
;; Functional definition of toplevel-macsyma-eval
(setq x (meval* x))
(dolist (fi finalevallist x)
(setq x (mfuncall fi x))))
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs