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

[mtewoodbury at gmail dot com]

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

--- Comment #13 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #12)
> 
> 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.)

Ahh. so 'We' is you and Andrew...  OK.

> 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.

Yes, but it would be very helpful if there is some indication that the
appropriate people have at least looked at the submission.  Something far short
of a commitment to do anything, but at least an acknowledgment that the ideas
have not been rejected out-of-hand.  'CONFIRMED' would do nicely.

>>>> 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).

That matches what I understand most open-source projects do.  Again, what is
missing is some indication that the submission has not fallen into oblivion.

>> 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.

Yes, paint the number of parameters as well as the spelling.  It was precisely
the lack of specificity of what put something in the 'hide set' that I was
going to have to study.  A demonstration that the resulting expansion is
bounded if the definition is extended would need to be added to that report.  I
could probably do it but it would take me a little while and quite a bit of
effort to get back into the mental mode to do it right.  Step 7.

Yes, it would be pairs, or triples.  Spelling, variadic flag and parameter
count with all spellings of a variadic macro hidden if its parameter count
matched or exceeded the current limit.  Additional expansions would temporarily
lower the limit.  Looks doable, even a bit fun...  Late undergrad or masters
level problem, not PhD, definitely not novice.