Re: Patch for %E formatting for C

[Gabriel Dos Reis <gdr at cs dot tamu dot edu>]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

| On Sun, 2 Oct 2004, Gabriel Dos Reis wrote:
| 
| > Also, %E really is for expressions, and identifiers are also
| > expressions.  There is no need to introduce artifical distinction and
| > comment #4 is right.
| 
| Although syntactically they are one case of expressions, at the level of 
| trees they have become the DECLs referred to by the identifiers, and an 
| IDENTIFIER_NODE is not something that should appear as an expression 
| operand in C.

I believe you're confusing different levels of abstraction.

At the very low level of program representation in front-ends, it
makes sense to distinguish between a plain identifier, a named
declaration and general expressions, just like integers are
reprensented using different formats from floating-point
representations, even though they may be both literals.

However, at higher levels (like unparsing or type inference), those
distinct representation formats are less relevant (that is rendered,
for example, in the "fake base class tree") and insistance on
migrating those low-level implementation details into the higher
levels is at best unhelpful noise and obfuscation.

|  Keeping in mind Nathan and Zack's proposal:
| 
|     With the exception of C++ template bodies, there are only a
|     few places where a tree node might or might not be an
|     identifier, and they are all arguably bugs.  The new C++ parser should
|     make it feasible to use custom data structures for C++ template
|     bodies, so that IDENTIFIER_NODE need not be an overloading candidate
|     at all. In some places, identifiers are used where unboxed strings
|     would suffice; we will remove all such identifiers in this step.
| 
| (p162 of the 2004 summit proceedings), the distinction seems far from 
| artificial, and a separate format for identifiers (e.g. %I) in due course 
| desirable.

While I'm very sympathetic to Nathan's proposal, I strongly disagree
with your %I proposal for unparsing;  we have no need for format
inflation.  

-- Gaby