As Dan said, this is basically a noun/verb issue. The system is
behaving as it should be (except for the parsing error I describe
below). If you'd like more explanation of the noun/verb system, just
ask.
But there are two other issues here.
--------------
First of all, you have found a parser bug, which I have reported as
864085:
x = >
is not legal syntax, and should be giving an error, just like x==, x=+,
and x=<. Thanks for finding this.
--------------
Secondly, I think you are being misled by Maxima's treatment of strings
on output (which is arguably confusing). In default 2-dimensional
output mode (display2d:true), strings are printed without quotation
marks (whether they represent operators or not):
(C1) "string";
(D1) string
(C2) is(d1=string); Note that this *looks like* D1, but is
different
(D2) FALSE
(C3) is(d1="string");
(D3) TRUE
But in 1-dimensional output mode, they are printed *with* quotation
marks so that they can be re-input. The String function uses
1-dimensional output mode, which can also be selected by settig
display2d:false:
(C4) display2d:false;
(D4) FALSE
(C5) "string";
(D5) "string"
(C6) is(d5=string);
(D6) FALSE
(C7) is(d5="string");
(D7) TRUE
This is similar to Lisp's print vs. princ.
If you want to compare the (2-d) external form of two objects,
string(x)=string(y) will not do that for you. In fact, I don't think
there is any standard way to do this.
In general, the noun/verb scheme is fairly reasonable for
integrate/limit/... But it is unnecessary and confusing for
sin/cos/..., and very screwed up for +/*/<. See my bug report 711539.
Fortunately, there is normally no reason to use noun/verb *except* for
integrate/limit/..., so even if the design and implementation are
problematic, they don't affect normal users.
Does this clarify things a bit?
-s