Print the brackets an operator that is not associative has

[Rafael-SOWNet]

Stringize prints an expression that parses back to a different expression, and in one case to a different truth value. The printed form is supposed to be a lie-free channel — AGENTS.md calls it a contract and StringizeRoundTripTest is where it is enforced — so this is the silent kind of defect that contract exists to prevent: a wrong reading is still a valid expression, so nothing throws.

"a implies (b implies c)"          prints  "a implies b implies c"       reads back as  (a implies b) implies c
"{1,2,3} \ ({2,3} \ {3})"          prints  "{1,2,3} \ {2,3} \ {3}"       reads back as  ({1,2,3} \ {2,3}) \ {3}
"{1,2} \/ ({3} \ {1,2})"           prints  "{1,2} \/ {3} \ {1,2}"        reads back as  ({1,2} \/ {3}) \ {1,2}
"{1,2} \ ({2} \/ {3})"             prints  "{1,2} \ {2} \/ {3}"          reads back as  ({1,2} \ {2}) \/ {3}
"2 * (3 mod 2)"                    prints  "2 * 3 mod 2"                 reads back as  (2 * 3) mod 2
"a in (b in c)"                    prints  "a in b in c"                 reads back as  (a in b) in c

Five of the six change the value, not only the tree:

	printed form means
false implies (true implies false) = True	False
{1,2,3} \ ({2,3} \ {3}) = { 1, 3 }	{ 1 }
{1,2} \ ({2} \/ {3}) = { 1 }	{ 1, 3 }
{1,2} \/ ({3} \ {1,2}) = { 1, 2, 3 }	{ 3 }
2 * (3 mod 2) = 2	0

The rule, and why it is one rule

The grammar folds every binary operator to the left except ^ and provided. So the printed form of a left-nested tree needs no brackets and the printed form of a right-nested one does — exactly when the operator, together with the others sharing its precedence level, is not associative. That is the rule -, /, mod and ^ already follow (<= on the right); the operators fixed here were the ones that did not.

Two of these are not obvious from the operator alone, which is why they were missed:

• \/ is associative and still mis-associated, because \/ and \ share one precedence level and are folded by one loop in the grammar. Union-on-union is safe; a set difference on the right of a union is not.
• * is associative and still mis-associated, because mod sits at the same level as * and /.

implies was a third case: the printer had <= on the left and < on the right — the rule the right way round for a right-associative implies, which is the conventional reading but not this grammar's. So it was over-bracketing (a implies b) implies c and under-bracketing the one that mattered, and the redundant brackets on the safe case are what made the ambiguous one look no different.

Same-shape verdict on every binary operator

AGENTS.md: "ask what else is the same shape, and fix that too, or write down why not."

	verdict
implies, \, \/ (against \), in, * (against mod)	fixed
+, and, or, xor, /\, \/ (against \/), * (against *, /)	left flat — associative, so re-association is invisible in the value. Measured on ground values rather than argued.
provided	left flat — folds right, and is value-associative in all four boolean combinations
-, /, mod, ^, !, the comparisons	already correct — the pattern this follows
piecewise, lambda, apply, matrices, function calls	call syntax, no associativity to get wrong

Bracketing the associative ones as well would be the strict entity-level reading of the contract, and it is deliberately not done here: "(a + b + c + d)^2".Expand() is right-nested throughout and would print as a ten-deep pile of parentheses. Both halves are now pinned by tests, so the flat half is a recorded decision rather than an oversight.

LaTeX

Fixed in the same shapes. I read CSharpMath.Evaluation's precedence table rather than assuming: it folds \cup, \setminus, \in, \cdot and \bmod left at the same groupings this grammar uses, so those get the same treatment — and it folds \to right, which is what Latexize's implies was already bracketing for, so that one is unchanged and was already correct. The change only ever adds \left(/\right) groups, which CSharpMath parses, so no matching PR is owed downstream (#822).

Measured

• 59 new tests, all passing. They assert entities and values, never printed text: AMisreadGroupingWouldChangeTheValue evaluates both sides, ANonAssociativeOperatorKeepsItsGrouping round-trips the tree, AnAssociativeOperatorPrintsFlatAndKeepsItsValue pins the deliberate flat half.
• Every changed output is in BREAKING-CHANGES.md, old value and new, measured on a build of each version rather than read off the diff.
• EveryNodeSurvivesEveryPipelineTest passes and KnownRoundTripFailures is untouched — that test builds one sample node per type with leaf children and never nests two operators at one precedence level, which is precisely the hole these defects lived in.
• Docs/Usage/Syntax.md said "everything groups to the left except ^". That was false for provided and had been since it was written. Corrected, with the two shared precedence levels noted.

Two things worth a maintainer's eye

1. implies associativity is a language decision, not a printer one. Mathematics, Lean, Coq, Agda, Haskell and CSharpMath all read → as right-associative; this grammar folds it left and Syntax.md documents that as deliberate. This PR makes the printer match the documented grammar. Changing the grammar instead is defensible and much larger — it moves the value of existing user input.
2. Stringize is used as a dictionary key in CommonDenominatorSolver.cs:95. While the round trip was broken, structurally distinct denominators could collide on one key. This narrows it; keying on printed text is a latent hazard worth its own look.

[Happypig375]

Implies associativity should be changed eventually to make it in line with how other people write it. Same for provided - left associativity is not useful because an AND operator within the condition represents the expression already.

[Rafael-SOWNet]

Thank you — and the second half of that comment found a defect in this PR, so I have pushed a fix rather than only replying.

provided already folds right, and has since it was written. The grammar says so in its own comment:

provided_expression returns[Entity value]
    : expr = implies_expression { $value = $expr.value; }
    ('provided' pred = provided_expression { $value = $value.Provided($pred.value); })?
    // note: even though Provided is associative, we parse it right-to-left matching natural language
    // "I'll go, provided you go, provided it's sunny" - Natural reading: I'll go ← (you go ← sunny)

What was wrong was Syntax.md, which claimed "everything groups to the left except ^" — false for provided since the day it was written, and this PR corrects it. So if Syntax.md is where the impression came from, that was my documentation's fault, and it is the reason the line is in the diff.

But that made provided the one case I got wrong here, and it is instructive. I classified it as safe using a value test, and by value it is safe — (x provided p) provided q and x provided (p provided q) are both x exactly when p and q hold. By expression it was not:

(x provided p) provided q   ->   x provided p provided q   ->   reads back as   x provided (p provided q)

Because it folds right, it is the left operand that mis-associates — the mirror of every other case in this PR. The round-trip contract is about the expression, and asking the expression is what catches it. Fixed in b78aacad, with LatexTests.Provided3/Provided4 updated: both built a left-nested Providedf and asserted it printed without the grouping, so they were pinning the ambiguity.

On implies

Agreed, and I would rather it were right-associative too — mathematics, Lean, Coq, Agda, Haskell and CSharpMath all read → that way, and CSharpMath reading it differently from us is a live inconsistency across a boundary we do not control.

I did not do it here on purpose, because it is a different size of change: it moves the value of existing user input. a implies b implies c means (a implies b) implies c today and would mean a implies (b implies c) after, and the two disagree — False implies True implies False is False now and True then. Nothing in a user's code would fail to compile; answers would just change. That wants its own PR, its own BREAKING-CHANGES.md entry, and a version number checked against #746.

This PR is strictly compatible with that happening: it makes the printer state the grouping the grammar actually has, so when the grammar moves, the printer's rule for implies flips from <=-on-the-right to <=-on-the-left and the round-trip tests already written here keep it honest.

Shall I open that as a separate issue and take it? I would rather have your answer on the version first — by the reckoning in #746 a changed answer has gone in a minor before, but this one changes a parse, which is a stronger break than any of those.

[Happypig375]

Maybe an issue on pending breakages would be appropriate. Remember to note to yourself to follow through on the next major version. Also, maybe noting down to promote experimentals and removing obsoletions would be appropriate.

[Rafael-SOWNet]

Done — #1019, "Pending breakages: changes agreed or arguable that cannot ship before a major version."

It opens with the criterion, since that is the part worth being strict about: a change belongs there when it moves the value of existing input or removes a published member. A changed answer has gone in a minor here, but every one of those was a wrong answer becoming right, and a deliberate convention change should not borrow that licence.

On it now:

1. implies right-associative — with the note that provided already folds right, so if implies moves, the two agree and Syntax.md's rule becomes "^, implies and provided group to the right". Worth settling in one go rather than twice.
2. FreeVariables / VarsAndConsts — your answer on FreeVariables leaks a set builder's %1 placeholder, and only a lambda counts as a binder #989 turned out to make that a three-property change, and it is breaking. VarsAndConsts returns bound names today: on the very example in its own XML docs, Lambda(x, x*2 + sin(y*pi)), it gives x, y, pi where free-variables-and-constants is y, pi. So it is wrong for lambda, not merely incomplete for the newer binders.
3. Promote or retire the 11 MathS.ExperimentalFeatures members — one pass, three possible verdicts each, and remove is why it is on a breakage list. "Experimental" is a promise about the whole namespace and it decays if it is never spent.
4. Removing obsoletions — worth recording that there are currently zero [Obsolete] members; 2.0.0 removed them all. So there is no backlog, and what belongs on the list is the rule: anything obsoleted during 2.x is removed at 3.0. 1.x accumulated a set precisely by never spending them.
5. Plus the three AGENTS.md already names as major-only — Roots vs fractioned powers? #204, Syntax for Piecewise? #326, Unify Codomain with a "provided ... in RR" condition #721 — and Complex Infinity #217, which changes 1/0 from NaN.

And the follow-through note is in the issue itself rather than in my head: it says it is to be read before the next major version is named, the same way #746 is read before any version is named.

This PR is unaffected — it makes the printer state the grouping the grammar actually has, which is right whichever way the grammar later folds, and the round-trip tests here keep the flip honest when it happens.