Re: Can't parse "a # not b", but parses "a # (not b)" and prints it as "a # not b"

I think this is generally a mess and perhaps people using Boolean values in
Maxima might reasonably be confused.
Perhaps judicious use of more warnings from the parser would help?
Right now in 5.48.1
  a=b=c;  --->
incorrect syntax: Found LOGICAL expression where ALGEBRAIC expression
expected

Why is this confusing? In addition to the mathematical vs programming
interpretation, the latter is unclear..
  In some programming languages the integer value  is used for false.
Python False==0 is true, I think.
  In lisp, (> 2 1)  is NIL, and there is an atom T for true.
  but in many circumstances anything not NIL is treated as true.. e.g.  (if
5 'a 'b)  returns A.
  In Maxima, ?nil   is printed as false,   not(?nil) or  ?t is printed as
true.
   the operator "="  does double duty as algebraic equivalence and Boolean
equality.
Some languages use = as assignment, which is not a help.  We could use ==
for something.

What kind of warning might work?
 maybe we could identify, at least when the Boolean operators are
explicit, how things are being parsed, just in case.

note that   (a=b)=c  and a=(b=c)  are accepted by Maxima...
somehow  a=b or b=a is parsed and returns false, 0 or 1 returns 0 or 1.
is(a=b) returns false. is (a or b) returns unknown.

yipes.




On Wed, Jun 10, 2026 at 9:28 AM Stavros Macrakis <[email protected]> wrote:

> Thanks for working on this.
>
> This is fine for logical expressions, and *a>b* can be considered a
> logical expression, so logically, interpreting *a>b = c>d* as *(a>b) =
> (c>d) *is not unnatural.
>
> However, I think most *mathematical* users (not system programmers) will
> expect *a=b=c *to mean *(a=b) and (b=c)*, and not *(a=b)=c*. Similarly,
> they "natural" mathematical meaning of *a>b=c* is either "don't do that"
> (which is what I think my math teachers would say) or maybe *(a>b) and
> (b=c)*. I think it will be a bad surprise for any user that it is
> interpreted as *(a>b)=c*, especially because:
>
>
> is((2=2)=true) => false
> is(equal(2>1,true)) => false
>
> assume(a>b)$
> is((a>b)=true) => false
>
> assume(equal(q,r))$
> is(equal(q,r)=true) => false
>
> Although it's true that legacy systems implementation languages follow the
> *(a<b)<c* interpretation, other symbolic math systems (Mathematica,
> Maple, SAGE) -- as well as Python -- follow the mathematical convention,
> and *a<b<c* means *(a<b)<c*.
>
>             -s
>
> On Wed, Jun 10, 2026 at 1:54 AM David Scherfgen via Maxima-discuss <
> [email protected]> wrote:
>
>> Dear all,
>>
>> as Stavros noted in this bug report
>> <https://sourceforge.net/p/maxima/bugs/4390/>, Maxima fails to parse
>> this:
>>
>> a # not b
>> Error: "Found LOGICAL expression where ALGEBRAIC expression expected"
>>
>> However, a # (not b) with parentheses parses perfectly, but is printed *without
>> parentheses*. This means that Maxima cannot parse its own output. (The
>> same for =.)
>>
>> *Proposed fix:*
>> In nparse.lisp, change lpos and rpos for the = and # operators from $expr
>> to $any. Also, increase the binding powers of  <, <=, >= and > from 80
>> to 85. Note that this is in accordance with most programming languages,
>> where <, <=, >= and > have a higher binding power than == and !=, for
>> the exact same reason of being able to compare logical expressions. Maxima
>> currently has them all the same.
>>
>> If we make this change, the following expressions will parse directly
>> without requiring parentheses, building the exact same trees they already
>> do:
>>
>> a # not b
>> a = not b
>> a = b = c (parses as (a = b) = c)
>> a > b = c (parses as (a > b) = c)
>> c = a > b (parses as c = (a > b), wouldn't parse with the original
>> binding powers)
>>
>> Would this have any unintended side-effects?
>>
>> Best regards
>> David Scherfgen
>> _______________________________________________
>> Maxima-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss