On Mon, 2014-05-05 at 19:37 +0200, Richard Biener wrote:
> On Mon, May 5, 2014 at 6:01 PM, Jeff Law <[email protected]> wrote:
> > On 05/05/14 02:22, Richard Biener wrote:
> >>>
> >>>
> >>> Also, AIUI, Andrew is looking at introducing concepts of gimple types and
> >>> gimple expressions, so "gimple" may no longer imply a *statement*.
> >>>
> >>> Alternatively, we could make the base class be just "gimple" (which would
> >>> be more consistent with the names of the accessor functions).
> >>
> >>
> >> I strongly prefer to name it 'gimple', not 'gimple_stmt'. Because it's
> >> less
> >> to type, and because it will make all other types shorter as well. And
> >> because
> >> 'gimple' _is_ a stmt right now, so gimple_stmt is redundant. Same applies
> >> to gimple_stmt_with_FOO, just make it gimple_with_FOO.
> >>
> >> I understand the namespace issue, but we don't have a namespace right now.
> >> Also gimple::gimple works just fine, no?
> >
> > But this approach is going to be inconsistent with Andrew's work, right?
> > ISTM we'd end up with something like...
> >
> > So statements would be "gimple"
> > types would be "gimple_type"
> > expressions would be "gimple_expr"
>
> Well, I hope that Andrew doesn't do without a namespace (and I still
> don't believe in what he tries to achieve without laying proper ground-work
> throughout the compiler). With a namespace gimple we can use
> gimple::stmt.
>
> > It's a bit of bikeshedding, but I'd prefer "gimple_stmt". If you really
> > feel strongly about it, I'll go along without objection, but it seems wrong
> > to me.
>
> Less typing. But yes, it's bikeshedding. Still gimple_stmt is
> redundant information in almost all context. 'stmt' was opposed to
> elsewhere so we settle on 'gimple' (which is already existing).
> IMHO not changing things is the best bikeshedding argument.
>
> >>
> >>> There's also the "bargain basement" namespaces approach, where we don't
> >>> have an implicit "gimple" namespace, but just *pretend* we do, and rename
> >>> the base type to "stmt", with e.g. "gimple_statement_phi" becoming just
> >>> "phi". ["gimple_switch" would need to become "switch_", say, to avoid the
> >>> reserved word].
> >>
> >>
> >> Ick (for the 'switch' case ... CamelCase anyone? :)).
> >
> > :-) Please, no....
>
> Agreed on that, btw. But switch_ can't be the answer either. Maybe
> swidch (similar do klass) or swjdch. Or swtch. I like swtch the best
> (similar to stmt).
FWIW I assumed the ick from Jeff was in relation to CamelCase.
Note that it's not just GIMPLE_SWITCH that has this problem when using
this naming convention; I believe the list of codes that would have
class names clashing with C++ keywords would be:
GIMPLE_GOTO
GIMPLE_SWITCH
GIMPLE_RETURN
GIMPLE_CATCH
GIMPLE_TRY
IMHO, I think trying to eliminate vowels or similar would be confusing
(e.g. how does one respell "try"? [1]) and that standardizing on a
trailing underscore for all of these seems to me to be cleaner and
simpler.
But, yeah, we're in bikeshedding territory here :)
Dave
[1] e.g. in patch 32 of the series which converts a dozen or so
"gimple" vars in tree-eh.c to be explicitly one of these. "trie" would
make me think of a data structure, rather than a "try" statement, and,
errr.... "trigh" would make me think of Battlestar Galactica's XO :)
