public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug preprocessor/58887] Allow recursion in varadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
@ 2013-10-26 21:13 ` pinskia at gcc dot gnu.org
2013-10-27 13:44 ` mtewoodbury at gmail dot com
` (11 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-10-26 21:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in varadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
2013-10-26 21:13 ` [Bug preprocessor/58887] Allow recursion in varadic macros? pinskia at gcc dot gnu.org
@ 2013-10-27 13:44 ` mtewoodbury at gmail dot com
2013-10-27 15:48 ` [Bug preprocessor/58887] Allow recursion in variadic macros? joseph at codesourcery dot com
` (10 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-27 13:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
2013-10-26 21:13 ` [Bug preprocessor/58887] Allow recursion in varadic macros? pinskia at gcc dot gnu.org
2013-10-27 13:44 ` mtewoodbury at gmail dot com
@ 2013-10-27 15:48 ` joseph at codesourcery dot com
2013-10-27 21:52 ` mtewoodbury at gmail dot com
` (9 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: joseph at codesourcery dot com @ 2013-10-27 15:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2013-10-27 15:48 ` [Bug preprocessor/58887] Allow recursion in variadic macros? joseph at codesourcery dot com
@ 2013-10-27 21:52 ` mtewoodbury at gmail dot com
2013-10-27 21:56 ` mtewoodbury at gmail dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-27 21:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2013-10-27 21:52 ` mtewoodbury at gmail dot com
@ 2013-10-27 21:56 ` mtewoodbury at gmail dot com
2013-10-28 11:35 ` mtewoodbury at gmail dot com
` (7 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-27 21:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2013-10-27 21:56 ` mtewoodbury at gmail dot com
@ 2013-10-28 11:35 ` mtewoodbury at gmail dot com
2013-10-28 13:38 ` joseph at codesourcery dot com
` (6 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-28 11:35 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2013-10-28 11:35 ` mtewoodbury at gmail dot com
@ 2013-10-28 13:38 ` joseph at codesourcery dot com
2013-10-28 13:56 ` joseph at codesourcery dot com
` (5 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: joseph at codesourcery dot com @ 2013-10-28 13:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2013-10-28 13:38 ` joseph at codesourcery dot com
@ 2013-10-28 13:56 ` joseph at codesourcery dot com
2013-10-28 17:48 ` mtewoodbury at gmail dot com
` (4 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: joseph at codesourcery dot com @ 2013-10-28 13:56 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2013-10-28 13:56 ` joseph at codesourcery dot com
@ 2013-10-28 17:48 ` mtewoodbury at gmail dot com
2013-10-28 18:51 ` joseph at codesourcery dot com
` (3 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-28 17:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2013-10-28 17:48 ` mtewoodbury at gmail dot com
@ 2013-10-28 18:51 ` joseph at codesourcery dot com
2013-10-30 10:04 ` mtewoodbury at gmail dot com
` (2 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: joseph at codesourcery dot com @ 2013-10-28 18:51 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2013-10-28 18:51 ` joseph at codesourcery dot com
@ 2013-10-30 10:04 ` mtewoodbury at gmail dot com
2013-10-30 16:56 ` joseph at codesourcery dot com
2013-10-30 19:00 ` mtewoodbury at gmail dot com
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-30 10:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2013-10-30 10:04 ` mtewoodbury at gmail dot com
@ 2013-10-30 16:56 ` joseph at codesourcery dot com
2013-10-30 19:00 ` mtewoodbury at gmail dot com
12 siblings, 0 replies; 13+ messages in thread
From: joseph at codesourcery dot com @ 2013-10-30 16:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug preprocessor/58887] Allow recursion in variadic macros?
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2013-10-30 16:56 ` joseph at codesourcery dot com
@ 2013-10-30 19:00 ` mtewoodbury at gmail dot com
12 siblings, 0 replies; 13+ messages in thread
From: mtewoodbury at gmail dot com @ 2013-10-30 19:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-10-30 19:00 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-58887-4@http.gcc.gnu.org/bugzilla/>
2013-10-26 21:13 ` [Bug preprocessor/58887] Allow recursion in varadic macros? pinskia at gcc dot gnu.org
2013-10-27 13:44 ` mtewoodbury at gmail dot com
2013-10-27 15:48 ` [Bug preprocessor/58887] Allow recursion in variadic macros? joseph at codesourcery dot com
2013-10-27 21:52 ` mtewoodbury at gmail dot com
2013-10-27 21:56 ` mtewoodbury at gmail dot com
2013-10-28 11:35 ` mtewoodbury at gmail dot com
2013-10-28 13:38 ` joseph at codesourcery dot com
2013-10-28 13:56 ` joseph at codesourcery dot com
2013-10-28 17:48 ` mtewoodbury at gmail dot com
2013-10-28 18:51 ` joseph at codesourcery dot com
2013-10-30 10:04 ` mtewoodbury at gmail dot com
2013-10-30 16:56 ` joseph at codesourcery dot com
2013-10-30 19:00 ` mtewoodbury at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).