> You have to defer the grouping of operands until well after the actual parse-time.
Why?
Well, in the case of my parser, I get back an S-expression corresponding to the groups (parentheses, braces, brackets) in the code, with each token inside that. So to group expressions, I then have to go over that, applying the macros in order of precedence. If I make operators purely left-to-right (with the exception of . , which has to be special-cased), I can do this grouping at the parser level and simplify things.
But if your macros have scope, isn't this a problem independent of operator precedence?
It's still a problem, as it is with any language with macros, but by letting operators have precedence that can change from file to file (or even worse, from function to function, if you're sadistic) would make it very difficult for people to track what's going on. With the pure left-to-right parsing, the behavior of operator grouping would be consistent regardless of anything else that's going on.
Why?
Well, in the case of my parser, I get back an S-expression corresponding to the groups (parentheses, braces, brackets) in the code, with each token inside that. So to group expressions, I then have to go over that, applying the macros in order of precedence. If I make operators purely left-to-right (with the exception of . , which has to be special-cased), I can do this grouping at the parser level and simplify things.
But if your macros have scope, isn't this a problem independent of operator precedence?
It's still a problem, as it is with any language with macros, but by letting operators have precedence that can change from file to file (or even worse, from function to function, if you're sadistic) would make it very difficult for people to track what's going on. With the pure left-to-right parsing, the behavior of operator grouping would be consistent regardless of anything else that's going on.