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

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this should go through the standards committee instead of being a GNU
extension.

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

[mtewoodbury at gmail dot com]

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

--- Comment #2 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Eventually, that is where this will go, but the committee is MUCH more
receptive of suggestions that have an implementation that people have had a
chance to play with.  GCC is one of the platforms where new ideas get tested. 
So, I believe it needs to be considered here.  

While I have not had news group access in recent years, I did watch and made
comments on the committee's action for more than a decade and it is implemented
extensions that get taken most seriously.

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

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
We take the view that the preprocessor is deliberately meant to be limited 
and overly complicated features in it would be contrary to the spirit of 
C.  Of course if they are introduced in the standard we need to implement 
them, but otherwise this proposed feature seems inappropriate.

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

[mtewoodbury at gmail dot com]

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

--- Comment #4 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #3)
> We take the view that the preprocessor is deliberately meant to be limited 
> and overly complicated features in it would be contrary to the spirit of 
> C.  Of course if they are introduced in the standard we need to implement 
> them, but otherwise this proposed feature seems inappropriate.

That has not always stopped you all in the past, but that is really neither
here nor there and you use the royal 'we' to boot...  Speak for yourself. 
(ignore that; I'm in a sour mood and you just pushed one of my hot buttons.)

Where option 1 may be a little complicated to implement, option 2, while less
effective, is a real simple addition: define __VA_ARG_COUNT__ (or maybe
__VA_ARGC__) with the same kind of restrictions that apply to __VA_ARGS__.

See also Bug 33877.

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

[mtewoodbury at gmail dot com]

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

--- Comment #5 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #3)
> We take the view that the preprocessor is deliberately meant to be limited 
> and overly complicated features in it would be contrary to the spirit of 
> C.  Of course if they are introduced in the standard we need to implement 
> them, but otherwise this proposed feature seems inappropriate.

That has not always stopped you all in the past, but that is really neither
here nor there and you use the royal 'we' to boot...  Speak for yourself. 
(ignore that; I'm in a sour mood and you just pushed one of my hot buttons.)

Where option 1 may be a little complicated to implement, option 2, while less
effective, is a real simple addition: define __VA_ARG_COUNT__ (or maybe
__VA_ARGC__) with the same kind of restrictions that apply to __VA_ARGS__.

See also Bug 33877.

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

[mtewoodbury at gmail dot com]

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

--- Comment #6 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
I have checked the code in libcpp.  The __VA_ARG_COUNT__/__VA_ARGC__
implementation looks quite feasible.  The heaviest impact looks to be new and
revised error messages and their translation.

I started to look at the possibility of doing actual recursion but ran out of
steam temporarily.  It might be necessary to copy hashnodes or, worse yet, add
a field to the hashnode structure.  Later...

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

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote:

> That has not always stopped you all in the past, but that is really neither

We have plenty of experience dealing with the consequent problems of the 
old habit of adding extensions because they seemed like a good idea at the 
time (or because a feature was supported in some language other than C, 
and there used to be an idea that GNU C should support all features of 
GCC's internal representation that could be accessed from any language 
supported by GCC) without any real effort in designing them at the level 
of precise proposed standard text to specify the feature.  Based on that 
experience, the bar for new extensions is much higher now.

Unlike recursion, __VA_ARGC__ seems like something reasonably well-defined 
and in accordance with the spirit of the preprocessor and unlikely to be 
problematic as an extension - but as you note, there's already a separate 
bug for it.

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

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
(And for recursion, even specification at the level of standard text might 
leave something to be desired; I'd think specification at the level of 
X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
name generated in macro expansion can itself be expanded, would be desired 
as well.  Not that I think recursion is appropriate to include in GCC's 
preprocessor unless it's standardized.)

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

[mtewoodbury at gmail dot com]

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

--- Comment #9 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #7)
> On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote:
> 
>> That has not always stopped you all in the past, but that is really neither
> 
> We have plenty of experience dealing with the consequent problems of the 
> old habit of adding extensions because they seemed like a good idea at the 
> time (or because a feature was supported in some language other than C, 
> and there used to be an idea that GNU C should support all features of 
> GCC's internal representation that could be accessed from any language 
> supported by GCC) without any real effort in designing them at the level 
> of precise proposed standard text to specify the feature.  Based on that 
> experience, the bar for new extensions is much higher now.
> 
> Unlike recursion, __VA_ARGC__ seems like something reasonably well-defined 
> and in accordance with the spirit of the preprocessor and unlikely to be 
> problematic as an extension - but as you note, there's already a separate 
> bug for it.

(Stop the 'we'!  Name or enumerate the group involved please.)

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

(In reply to joseph@codesourcery.com from comment #8)
> (And for recursion, even specification at the level of standard text might 
> leave something to be desired; I'd think specification at the level of 
> X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
> name generated in macro expansion can itself be expanded, would be desired 
> as well.  Not that I think recursion is appropriate to include in GCC's 
> preprocessor unless it's standardized.)

Hmm.  Is X3J11/86-196 the pdf that shows up at the top of a Google search?
If so, I'll need to go over it fairly carefully.  A quick review left me with
the impression that determining when to allow additional expansion involved a
bit of hand-waving.

So, the description of what should expanded has to be carefully worked out
before any implementation is released.  Indirect recursion would be part of the
package.

I am trying to look at the reasons behind the specifications in the standard. 
In the case of 'no recursion' it was obvious that simple recursion was a snake
eating its own tail and as originally specified could not be anything else. 
With the addition of variadic macros, a self limiting form of recursion becomes
possible.  With the proper hedges in place it would have the same kind of power
that variadic functions posses.  As things currently stand, variadic macros
have apparently arbitrary limitations that reduces their usefulness.  With an
intelligent design, this would be where the language aught to be going.

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

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 28 Oct 2013, mtewoodbury at gmail dot com wrote:

> (Stop the 'we'!  Name or enumerate the group involved please.)

Well-established consensus among the GCC maintainers about what sorts of 
features are appropriate to add and what sorts of features cause problems.  
It's not as if the preprocessor has lots of active development with 
disagreement among its developers about what should go in; it's rightly 
pretty stable in terms of features with only occasional bug fixes or new 
features (mainly coming from WG21) needed.

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

> (In reply to joseph@codesourcery.com from comment #8)
> > (And for recursion, even specification at the level of standard text might 
> > leave something to be desired; I'd think specification at the level of 
> > X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
> > name generated in macro expansion can itself be expanded, would be desired 
> > as well.  Not that I think recursion is appropriate to include in GCC's 
> > preprocessor unless it's standardized.)
> 
> Hmm.  Is X3J11/86-196 the pdf that shows up at the top of a Google search?

Yes.

> If so, I'll need to go over it fairly carefully.  A quick review left me with
> the impression that determining when to allow additional expansion involved a
> bit of hand-waving.

The point is it defines, through the pseudocode functions, exactly how 
hide sets (the sets of macros for which expansion is currently suppressed 
because it would be recursive) are determined - it's the pseudocode that 
you need to study more than the surrounding text.  And it's this algorithm 
that GCC is intended to follow.  So anything allowing new forms of 
recursion needs to explain how this algorithm is affected.

> possible.  With the proper hedges in place it would have the same kind of power
> that variadic functions posses.  As things currently stand, variadic macros
> have apparently arbitrary limitations that reduces their usefulness.  With an
> intelligent design, this would be where the language aught to be going.

I suggest that the language ought not to be going in the direction of 
adding much power to the preprocessor at all - that expressive power 
belongs in the language, not the preprocessor (and that it's fine to use 
programs to generate C program text if neither is convenient for what you 
want to do).

Obviously you can experiment with adding a feature to GCC's preprocessor 
in preparation for submitting it to WG14 - and detailed definitions in 
terms of pseudocode algorithms and proposed standard text will be helpful 
for that as well.  But for actual inclusion in mainline GCC, you need to 
convince the maintainers that it's desirable for such features to be 
present in the preprocessor at all - that they are worth the maintenance 
burden that any feature imposes (which includes being well-enough defined 
that reimplementing a bit of the compiler won't change them incompatibly, 
rather than doing things in ways that are accidents of the implementation 
and so hard to specify and keep compatible over time).

Sometimes a development branch is a better place for gaining experience 
with an experimental feature than mainline, until the standards committees 
reach a conclusion on the feature and how to specify it (that was done 
with C++ concepts, for example).

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

[mtewoodbury at gmail dot com]

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

--- Comment #11 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #10)
> On Mon, 28 Oct 2013, mtewoodbury at gmail dot com wrote:
> 
>> (Stop the 'we'!  Name or enumerate the group involved please.)
> 
> Well-established consensus among the GCC maintainers about what sorts of 
> features are appropriate to add and what sorts of features cause problems.  
> It's not as if the preprocessor has lots of active development with 
> disagreement among its developers about what should go in; it's rightly 
> pretty stable in terms of features with only occasional bug fixes or new 
> features (mainly coming from WG21) needed.

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
its entirety.  In that, you overstate your case.  If you had said 'As an old
hand at this' instead of 'We', I would not have objected.

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

On the other hand, 'unconfirmed' is really not a status that applies to
requests for enhancements.

>> (In reply to joseph@codesourcery.com from comment #8)
>>> (And for recursion, even specification at the level of standard text might 
>>> leave something to be desired; I'd think specification at the level of 
>>> X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
>>> name generated in macro expansion can itself be expanded, would be desired 
>>> as well.  Not that I think recursion is appropriate to include in GCC's 
>>> preprocessor unless it's standardized.)
>> 
>> Hmm.  Is X3J11/86-196 the pdf that shows up at the top of a Google search?
> 
> Yes.
> 
>> If so, I'll need to go over it fairly carefully.  A quick review left me with
>> the impression that determining when to allow additional expansion involved a
>> bit of hand-waving.
> 
> The point is it defines, through the pseudocode functions, exactly how 
> hide sets (the sets of macros for which expansion is currently suppressed 
> because it would be recursive) are determined - it's the pseudocode that 
> you need to study more than the surrounding text.  And it's this algorithm 
> that GCC is intended to follow.  So anything allowing new forms of 
> recursion needs to explain how this algorithm is affected.

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

On the other hand, your summary adds vary little to what the pdf contains...

> 
>> possible.  With the proper hedges in place it would have the same kind of
>> power that variadic functions posses.  As things currently stand, variadic
>> macros have apparently arbitrary limitations that reduces their usefulness.
>> With an intelligent design, this would be where the language aught to be
>> going.
> 
> I suggest that the language ought not to be going in the direction of 
> adding much power to the preprocessor at all - that expressive power 
> belongs in the language, not the preprocessor (and that it's fine to use 
> programs to generate C program text if neither is convenient for what you 
> want to do).

That is a very old argument and fallacious on its face.  The preprocessor is
part of the language.

External code generators create new languages.  Those new languages will never
get the level of acceptance that 'C' has.  Each generator represents an
additional layer in a project's development and requires an investment that has
to be justified.  Further, that kind of development calls for skills that many
projects simply can not justify.  Adding an external code generator to an
implementation can also preclude that implementation from consideration for
legal reasons while extending 'C' by using macros would not run into the same
bar.  Po-poing the preprocessor this way just isn't on. 

> Obviously you can experiment with adding a feature to GCC's preprocessor 
> in preparation for submitting it to WG14 - and detailed definitions in 
> terms of pseudocode algorithms and proposed standard text will be helpful 
> for that as well.  But for actual inclusion in mainline GCC, you need to 
> convince the maintainers that it's desirable for such features to be 
> present in the preprocessor at all - that they are worth the maintenance 
> burden that any feature imposes (which includes being well-enough defined 
> that reimplementing a bit of the compiler won't change them incompatibly, 
> rather than doing things in ways that are accidents of the implementation 
> and so hard to specify and keep compatible over time).

So let the maintainers think about it and do not throw false arguments into the
discussion.  The process should proceed more or less along the following lines:

1)  Define how the 'no-recursion' rule can be changed so that the result is
    most useful and least problematic from the language user's point of view.

2)  Identify _what_ needs to be changed in GCC to effect that change.  To
    some extent this includes _where_ and _how_ GCC might implement the
    change, but this step really addresses high level considerations, not
    details.

3)  Asses the amount of effort that would be required to properly
    evaluate the change.

4)  If the resources identified in step 3 are available, evaluate and
    review the expected impact of the change.  This step will also
    answer questions about the expediency of making such a change.

5)  If resources identified in step 4 are available, identify a specific
    solution, evaluate its likely effectiveness and impacts.

6)  If the resources identified in step 5 are available, implement and test
    the proposed solution.  Ideally, the change should have an option that
    turns it on and off.

7)  Use the trial solution to update the specification from step 1 and turn
    it into a formal specification.

8)  Get some experience with the solution and repeat steps based on that
    experience.

9)  Formal standardization process...

We are not even into step 1 yet.

> Sometimes a development branch is a better place for gaining experience 
> with an experimental feature than mainline, until the standards committees 
> reach a conclusion on the feature and how to specify it (that was done 
> with C++ concepts, for example).

That is probably a step 5 action, so you are jumping the gun a bit here.

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

[joseph at codesourcery dot com]

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.

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