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

I guess I'm a little late to the party. Anyway, about these changes.

(1) change RPOS and LPOS for = and #.

(2) change RBP and LBP for inequality operators.

These are both OK by me. These both make it possible to parse some
expressions which trigger errors now, and don't change any existing
expressions which don't trigger an error (right?).

It doesn't bother me that it's a bit of a stretch to figure out what a
= b > c means. By assigning binding powers, we give it an unambiguous
representation -- it must be a = (b > c). What does that "mean"? We
don't need to know. If that's not suitable for some use, then we just
say "Don't do that." We set up the rules and let the user figure out
what is meaningful to them  -- that is, I claim, the mathematical
approach.

I think (1) was somewhat less controversial than (2). Maybe if we
can't get everybody on board for (2), we can still consider (1).

FWIW & all the best.

Robert

On Tue, Jun 9, 2026 at 10:59 PM David Scherfgen via Maxima-discuss
<[email protected]> wrote:
>
> Dear all,
>
> as Stavros noted in this bug report, 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