#3111 to_poly_solve error when declare(a,constant) before loading

[bigfooted]

I get an error when I declare the constant "a" before loading
to_poly_solve. This is happening when declaring "a" or "b" but not "c"
or "_a".

(%i1) declare(a,constant);
(%o1)
done
(%i2) load(to_poly_solve);
WARNING: DEFUN/DEFMACRO: redefining macro OPAPPLY in
/home/nijsob/mathematics/maxima-5.37.3/share/fourier_elim/fourier_elim.lisp, was defined

in /home/nijsob/mathematics/maxima-5.37.3/share/to_poly_solve/to_poly.lisp
WARNING: DEFUN/DEFMACRO: redefining macro OPCONS in
/home/nijsob/mathematics/maxima-5.37.3/share/fourier_elim/fourier_elim.lisp, was defined

in /home/nijsob/mathematics/maxima-5.37.3/src/binary-clisp/nummod.fas
define: in definition of one_to_one_reduce, found bad argument a
-- an error. To debug this try: debugmode(true);

[Rupert Swarbrick]

I think Maxima is doing the right thing here: you're just asking it to do something a bit odd. If you write declare(a, constant), this means "treat a as a symbolic constant, whose value is some fixed number". This allows you to define new constants that work a bit like %pi or %e.

Inside the code for to_poly_solve, there is a function (one_to_one_reduce) that has a as a parameter. You can see the same error if you write something like this:

declare(a, constant);
foo (a) := 1 + a;

Maxima quite reasonably refuses to evaluate the second definition: it's akin to having written foo(%pi) := 1+%pi. Maybe you've just told me how to evaluate foo at 3.141, but I don't know how to evaluate it anywhere else...

Please reply again to this report in the next couple of days if what I've just written doesn't explain what's going on, else I'll close the report when I next come past.

[bigfooted]

I understand what is going on, I just do not think that code that comes with maxima should have name clashes for variables like a,b,c, etc and I think this should be fixed. A user should be able to use any normal variable name like a,b,x,y,eq,var, etc without getting errors just because some call to a maxima function also uses 'a'. Using a convention for internal variable names, like an underscore prefix, would alread fix this problem and probably any name clash problem if this convention is used consistently throughout the code.

[Rupert Swarbrick]

Sorry, I don't think this demonstrates that you understood what I tried to explain. The point is that the declare(xxx, constant) feature is a rather low-level mechanism that allows the user to define a new constant. The resulting thing doesn't make sense as a variable any more (just like %pi and %e don't).

You can reasonably argue that existing code should somehow be able to ignore newly declared constants. I think that probably the only way to do that sensibly is to introduce some form of namespaces (something that Robert Dodier has mused about in the past?). However, I don't think a bug report is the right place to track such a large new language feature. Maybe discuss it on the mailing list?

[bigfooted]

I'm sorry, I see that in my reply I said variables a,b,c, which is not what I meant. I want "a" to be a constant like %pi and %e. And at the same time I want to_poly_solve to still work and not force me to use constant "c". Anyway, I asked about this on the mailing list and Barton Willis asked me to file a bug report. Robert Dodier said it is scope confusion. I agree that if you want to solve this for the entire maxima cas, it is indeed a big issue. I do think it is an issue that needs to be solved, but maybe not through this bug report. Thanks for your input.