My guess:
The difference is probably that you are asking the
maxima display program, in the first place, to
display something like ( $f1 ), whereas you need
something like ((mlist) $f1)
Try changing the first version to
(cons '(mlist) (push f finalevallist))
instead of (push f finalevallist)
.
For the second version, the format function returns nil,
or "false" and it is being passed through f() to return
false^2.
The macsyma idiom that you may want to adopt is for
$finalevallist to be a macsyma list with a ((mlist) header,
and to use uh, mpush? is there one? to mcons? on to
the front of that list, and have some mmap along that
list...
(etc).
I'm not sure that finalevallist is quite the right name
for all this.
You might want to make it clear that this is done post-command
execution. In a more general setting you might want to pre and post
"wrap" a command. kind of like tellsimp and tellsimpafter on
the currently unnamed
top-level-eval of the read-eval-print loop.
Maybe this would be the way to implement it, in fact.
have an "identity" function called $top_level_eval. Then
allow tellsimpafter(top_level_eval(ANYTHING), f(ANYTHING)).
Actually, you may need 2 functions, pre_top_level_eval and post_top_level_eval,
and tellsimpafter on the 2nd one.
Just thinking out loud.
RJF
C Y wrote:
> 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
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima