hi barton,
context -- DEFMVAR puts symbol/value pairs into a table.
reset runs through the symbols and binds them to their values.
reset is strange.
some DEFMVAR variables are assigned values which aren't maxima
expressions, so reset has to print values as lisp objects.
some interesting global variables aren't declared w/ DEFMVAR.
some items which probably shouldn't be susceptible to rebinding
are on the list, e.g. a list of small primes.
reset is all or nothing, i.e., can't reset a subset of variables.
after calling reset, run_testsuite fails (due to a problem with
declare (foo, antisymmetric), other declarations are still OK).
about modifying reset, how about this.
(1) reset prints a message about X only if reset actually
modifies X, or maybe not at all.
(2) reset accepts arguments to tell it what to reset.
probably reset should work like kill.
(3) reset prints stuff as maxima expressions instead of lisp expressions.
(4) review DEFMVAR declarations and change lisp-only objects
to DEFVAR instead (to enable item 3).
(5) make an attempt to find global variables which are not
DEFMVAR-declared and change them to DEFMVAR so
that reset (and potentially other functions) knows about them.
the declare (foo, antisymmetric) bug would have to be investigated,
i guess.
> (3) invent a uniform mechanism for controlling warnings and other
> messages.
well, we should try to merge such a mechanism into existing output functions.
can we set the verbosity level by verbosity : <whatever> instead of
using the property system? i find the lack of distinction among the
arguments of "put" confusing.
how about this:
foo () := (print_debug ("factoid"), print_info ("advisory"),
print_error ("oops"));
print_output_level : 'print_error;
foo (); => oops
print_output_level : 'print_info;
foo (); => advisory oops
print_output_level : 'print_debug;
foo (); => factoid advisory oops
in this scheme, print_debug, print_info, and print_error all
take the same arguments as print.
it's likely that other debug / logging schemes have been
invented for lisp, maybe we should try to find one.
comments?
robert