[Bug preprocessor/58887] Allow recursion in variadic macros?

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:

> I think I understand consensus, but I only hear your voice here, not the voice
> of a multitude.  You may be part of the consensus you speak of, but you are not

I was agreeing with Andrew.  Jason, the other maintainer likely to review 
libcpp patches, hasn't commented on this issue.  (There are plenty of 
others who *can* review such patches but are unlikely to do so in 
practice.)

That someone doesn't reply to some point (if they read it) only indicates, 
at most, that they do not have anything to add that has not already been 
said adequately somewhere in the totality of the discussion, rather than 
whether they agree or disagree.

> >> But that bug was filed on the wrong component and has languished for YEARS
> >> as a result of that miss-filing.  It looks like no one has looked at its
> >> problem seriously...
> > 
> > That maintainers wouldn't necessarily object to the addition of a feature 
> > doesn't mean any maintainer has any interest in implementing it.  There 
> > are lots of "bugs" filed suggesting some vaguely reasonable new feature 
> > that was of interest to the submitter but not of sufficient interest to 
> > anyone wanting to implement it (but not rejected either, because the 
> > feature might well be accepted if implemented).
> 
> I have worked for companies where there was a formal definition of roles, and
> what you describe is something from that world.  On the other hand, I believe
> open-source projects like GCC have less authoritarian structures and that such
> decisions are much less formal.  In other words, membership in 'maintainers' is
> consensus based on merit, not the open and shut rule of corporate structure.

Bugs languish because the maintainers - and other developers who might fix 
them - are individuals, there is indeed no formal structure as regards 
reviewing bugs or assigning people to fix them, and each individual who 
looked at it was not interested in implementing the feature / fixing the 
bug.  Misfiling is only a minor part - it could be relevant, if someone 
had gone through all the "preprocessor" bugs, implementing lots of things, 
and missed that one because it wasn't a "preprocessor" bug - but it so 
happens no-one has been active in that way with preprocessor bugs lately.

Maintainers are appointed by the Steering Committee (based on merit) (but 
someone's views on a patch or feature can be relevant and useful without 
them being a maintainer who can approve the patch).

> As I said, I need to go over it carefully.  It is obviously pseudo-code and
> both the code and the explanation deserve careful study.  Where it has built in
> the no-recursion rule was not quite obvious at first glance, thus the remark
> about hand waving.  Again, I need to study it carefully, and I have not done
> that yet...

No-recursion is built in through hide sets - that is, each token has at 
each time an associated set of names of macros that cannot be expanded if 
encountered when expanding that token.  Thus, when expanding a macro M, 
the name M is added to the hide sets of the tokens in the expansion before 
they, and the rest of the input, are considered for reexpansion (for 
details see the pseudocode).

Some discussions of C macro expansion use the term "blue paint" when 
discussing the rules for recursion.

Your proposal is apparently something that means a macro is no longer in 
or out of a hide set, but in a state meaning whether it can be expanded 
depends on the number of parameters.  Maybe the hide sets will need to 
contain pairs (macro, number of arguments), or something like that, 
instead of just macro names.