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
>>>>> "Per" == Per Bothner <per@bothner.com> writes:
Per> Mark Mitchell <mark@codesourcery.com> writes:
>> Well, it's a statement, not an expression.
Per> Those of use spending a lot of time in the Scheme/Lisp world
Per> don't accept that as a valid distinction!
In Scheme/Lisp it's not. I think it's actually a mistake to try to
come up with the One True Representation for all programming
languages; they're internals are wildly different.
What we've done for C++ has worked very effectively; I have no reason
to think it wouldn't work for C as well. Whether it would work for
Fortran, I don't really know. I don't think it would make sense for
Lisp, Forth, or Prolog.
One general principle of object-orientation is that you should make
programmatic objects that correspond to objects in your application
domain. Statements and expressions are very different things in
C/C++; it makes a lot of sense for them to be different things
internally as well.
You're right that you could represent these things in lots of ways.
On the other hand, I've worked on no less than four C/C++ compilers,
all of which had a notion of `if statement' as opposed to `conditional
expression'. It's not that we shouldn't break with existing practice
if there's a good reason -- but we also shouldn't neglect years of
experience, in GCC and elsewhere, with methods that work.
Per> redundant and wastes space. Worse, it is incompatible with
Per> the hierarchical AST model that tree nodes are.
You argued this again below as well. But the way this works is
exactly analagous to a CALL_EXPR, for example. A CALL_EXPR has as its
children a list of operands, all of which are chained together. A
COMPOUND_STMT has as its children a list of statements which are
chained together. So, in fact, this practice follows existing
methodology in GCC.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com