Re: Infix/postfix/nary redefinition issue (was loading to_poly_solve has side-effect).

Thanks for working on it, Serge, that's terrific.

I looked at the patch and it looks OK to me, except it appears that
EXPLODEN may be called repeatedly (I'm not sure how often one would
fall into that branch, so maybe it will happen while parsing every
operator and maybe it will happen only under specific conditions). Not
a big deal, it doesn't affect correctness, but has the potential to
introduce an inefficiency in the parser.

The tests look OK to me, although I think some of the tests which look
like string(parse_string(a op b)); "a op b"; could be made stronger by
omitting the call to string. Since these tests are expected to pass,
barring a regression in the parser, it's OK by me to be optimistic and
write the expected result as a op b; or, if you don't want to trust
the parser, to write it as "op"(a, b); This latter form (ordinary
function call with the operator name as a quoted string) might be
suitable for other tests as well.

The underlying problem is that the Maxima parser, since time
immemorial, stops as soon as it has enough characters for an existing
operator; that is why it gets confused about operators such that one
is a prefix of the other. The bug fix, and I agree this is a bug, is
to wait for a symbol terminator before looking for a match in the
operator list; if I have understood the patch, that is just what the
patch does. The various operator-defining functions are really only
incidental to this problem -- they are just the means by which
problematic operators are constructed.

I'm happy with the bug fix -- the parser patch looks OK and the bit
about fixing the data structure is a good catch -- but there's lots of
stuff about the operator-defining functions and there's stuff
wandering into the documentation for them. It isn't actually required
for the arguments to be strings, they can be symbols, so the suggested
documentation change is an incorrect digression.

I find the handover document rather grating -- the *insistent* tone of
the apparently **unnecessary** '''emphasis''' wears on me after a
while -- but I guess that's a small price to pay. The larger problem
is that the document makes a lot of hay about stuff which is not
immediately related to this particular bug.

Any change to the parser has the potential to change existing code --
I don't know if there are any files in .mac in maxima/share which are
counting on the current behavior, but it is probably a good idea to
look. I guess one could look for operator definitions and see if there
are any instances of foobar where foo is a user-defined operator.

Thanks a lot for working on the bug, this is very useful.

All the best,

Robert