But that still doesn’t explain that. There is no sense in C++ that (a OPERATOR b) is ever going to give you a different result from ((a) OPERATOR (b)) if a and b are atoms/symbols/whatever-you-call-them. No matter how many bugs or misunderstandings there are about precedence.
Hm… is it possible to overload the parentheses in C++?
(Wonderful (username), (by) the (way)!)
Argh. Oh god. Yes there is, but AFAIK not for (parentheses); but you can overload parentheses(…), and I think also parentheses[ … ] - like that; based on the type of the var named “parentheses”. Pure “grouping” parentheses cannot be overloaded I think.
Cheers 
I’d only call the first set of groupers (parentheses), and the second [square brackets], as distinct from <angle brackets> and {curly brackets}. But then, I’m an American. Here’s some other schemes I know of and an apposite poem.
Sure, but the reason it would be more difficult than necessary to make macros work would be because of the introduction of irregularity into the syntax… The reason that Lisp is such a macro-friendly language is precisely because the syntax is so simple and uniform.
Right. I was just aiming my reply at people who want a tangible result as opposed to a theoretical one, but of course the tangible result is a direct consequence of the improved abstract purity.
Ah, gotcha.
That habit may be a holdover from when macros ruled the C/C++ world. Given
#define MULTIPLY(a, b) a * b
and
k = MULTIPLY( 3 + 4, 5 + 6 );
you’d get k = 29 and scratch your head a lot. And then you’d start putting parentheses everywhere, just in case.