This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: function-at-a-time processing in C
Mark Mitchell <mark@codesourcery.com> writes:
> Well, it's a statement, not an expression.
Those of use spending a lot of time in the Scheme/Lisp world don't
accept that as a valid distinction!
> So, for example, it has a line number,
That is not a useful distinction. Expressions can have line numbers.
In fact, there is a tree type specifically to associate line numbers
with expressions: EXPR_WITH_FILE_LOCATION.
(Apropos: One of these days I would like to make some progress into
better support in gcc for *column* numbers, as discussed previously.)
> and a pointer to the next statement.
Again, a bogus distinction. An expression also has a next expression.
Including a pointer to the next statement in the tree structure is
highly undesirable. For one thing it is redundant and wastes space.
Worse, it is incompatible with the hierarchical AST model that
tree nodes are. It complicates sharing (which you may not want to do
anyway), and tree re-arranging.
The Java front-end has managed fine without "next" pointers;
I gather the C++ front-end uses them. But that is a flaw, not a
feature.
> Third, why are there separate FOR_STMT, WHILE_STMT, DO_STMT?
> They are all variants of each other. In fact, they are all special
> cases of LOOP_EXPR. Using separate tree codes means useless extra code,
> and more difficulty writing optimizers.
>
> It also means a representation that looks more like the source
> program. That's essential in some cases (templates),
The proper way to do that is with some kind of annotation. For
example we can have a flag in the LOOP_EXPR which indicates whether
the LOOP_EXPR was orginally a for, a while, a do, or something else.
This is basically what Java does: It has a FOR_LOOP_P flag to
indicate whether the LOOP_EXPR was originally a for statement.
> As above, these things are statements, not expressions.
As above, a meaningless disctinction, at the semantics level,
which is what tree nodes are supposed to represent.
> This is strange way to represent a scope.
>
> Agreed -- but it turns out to be strangely practical.
Were it my decision, I would insist on a better motivation
for something that so violates the tree model of tree nodes.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/