Most parts of Maxima incorrectly treat Maxima strings
(e.g. "foo") as variables, not as manifest constants.
This is understandable, since they are represented
internally as Lisp symbols, but is still incorrect.
A few places get it right. For example, setting a string
to a value ("f":3) gives an error. But note that mset
doesn't even use the standard mstringp predicate....
In many places, the problem with strings is simply that
illegal operations don't give errors, e.g. depends("f",g).
But in other places, meaningful operations give incorrect
constantp("foo") => false BAD
This is easy to fix, and the runtime overhead shouldn't
be an issue nowadays. Though perhaps it would be
better to give string symbols an explicit plist property.
orderlessp(foo,"foo") => true, though the convention is
that all manifest constants come before variables. Cf.
sort([2,%pi,foo,"foo"]) => [2,%PI,foo,"foo"]
Probably the biggest problematic area is in
comparisons. Since string comparisons don't work,
strings become pretty useless in Maxima programming.
The following comparisons give errors:
is("a" # "b")
Though the following predicates work correctly:
is("a"="a") => true
is("a"="b") => false
is("a" # "a") => false
is("a" # "b") => true
is("a"<="a") => true
is(equal("a","a")) => true
Not by coincidence, the correct cases are those where
the rules for variables give the correct result....
Of course, it would be better to convert Maxima strings
to use Lisp strings, but in the meantime.... Note, by the
way, that Maxima DOES depend on the fact that strings
are interned to do things like put the OPR property on
&+. But this can of course be fixed.
Maxima 5.9.0 GCL 2.5.0 mingw32 Windows 2000