In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> wrote:You're describing a 'Concrete Syntax Tree' or CST, versus AST.On 31/05/2026 10:49, David Brown wrote:This is all a bit of a distraction from the original point thatOn 31/05/2026 10:12, Richard Harnden wrote:>On 31/05/2026 00:43, Keith Thompson wrote:>C's operator precedence rules are complicated and arguably flawed.>
They could have been defined differently. A simpler set of rules,
with fewer levels,*might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.
Can't the compiler easily remove any parens that aren't necessary?
So - just write complex expressions in a way that a human can most
easily understand, it makes your intention clear and probable doesn't
increase the size of the executable.
Of course. Parentheses do not affect the generated code unless they
affect the semantics of the expression. (Some people think parentheses
affect the order of evaluation,
They can do if they make a expression be parsed differently. Do you have
an example where they make no difference but people might think they do?
David and Richard Harnden were trying to make, which seemed
clear enough to me, but perhaps should have been given with a
better example. Maybe something like:
d = a*b + c;
Is equivalent to,
d = (a*b) + c;
And in this case, the parentheses are superfluous and don't
change the order of evaluation of the expression as far as the
language is concerned. Whether a compiler rearranges it in
generated code in a way that is more convenient of faster or
whatever is another matter.
I would quibble with this idea that the compiler "removes"
parentheses. I get the intuition, but C is not Go where the
compiler "inserts" semi-colons for you, and has no analogous
concept. Rather, as I think Keith said, expressions are parsed
into some internal representation, and then transformed into
something like an abstract syntax tree, where syntactic
notations like parentheses are lost.
Both expressions above correspond to an AST like:
┌───────┐
│BinOp +│
└───────┘
╱ ╲
╱ ╲
┌───────┐ ┌───────┐
│BinOp *│ │Sym `c`│
└───────┘ └───────┘
╱ ╲
╱ ╲
┌───────┐ ┌───────┐
│Sym `a`│ │Sym `b`│
└───────┘ └───────┘
But the to get to that, it may be that the compiler uses a
different initial representation, like a parse tree that more
closely resembles the source language grammar. Here, the
two expressions might have different parsed representations.
E.g., for the first, simplifying heavily, may look something
like this:
┌──────┐
│ expr │
└──────┘
╱ │ ╲
╱ │ ╲
┌─────┐ . ┌─────┐
│term │ (+) │term │
└─────┘ ' └─────┘
╱ │ ╲ │
╱ │ ╲ │
┌─────┐ . ┌─────┐ ┌─────┐
│ident│ (*) │ident│ │ident│
└─────┘ ' └─────┘ └─────┘
│ │ │
│ │ │
.─. .─. .─.
(`a`) (`b`) (`c`)
`─' `─' `─'
While the second might add an extra `expr` node, as in:
┌──────┐
│ expr │
└──────┘
╱ │ ╲
╱ │ ╲
┌──────┐ . ┌─────┐
│ expr │ (+) │term │
└──────┘ ' └─────┘
│ │
│ │
┌─────┐ ┌─────┐
│term │ │ident│
└─────┘ └─────┘
╱ │ ╲ │
╱ │ ╲ │
┌─────┐ . ┌─────┐ .─.
│ident│ (*) │ident│ (`c`)
└─────┘ ' └─────┘ `─'
│ │
│ │
.─. .─.
(`a`) (`b`)
`─' `─'
I believe that the answer, for most compilers that parse and
then convert to an AST, the second is more likely to be created
than the first. However, given that the same AST is created
from both parse trees, this is unlikely to have an effect on the
object code ultimately output from the compiler.
Although in that case, I expect to see a discrete node for bracketed expressions (ie. parenthesised), as those would also have a distinct production in any formal grammar.
Personally I don't have much use for CSTs for a normal compiler, but they might be useful for source-to-source translators, or programs that do source refactoring, where you want to preserve extras such as parentheses even if they're not strictly needed.
(Injecting the right parentheses for examples like `(a + b) * c' which would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to just follow the original source!
In any case, that still wouldnt't turn ((a+b)) back into the original; you'd need a suitable CST.)
Les messages affichés proviennent d'usenet.