This is the mail archive of the
mailing list for the GCC project.
Re: Reenabling Ada by default
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: ghazi at caip dot rutgers dot edu
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 9 Sep 04 16:33:43 EDT
- Subject: Re: Reenabling Ada by default
Grr, it's really frustrating that you use lack of expertise as an
argument for maintaining your behavior.
So your argument doesn't wash and I see no reason you should feel
entitled to behave differently than the rest of the community.
Just to be clear here that the "you" above does not apply to me personally
since I'm not one of the people making patches to the Ada front-end. I do
work on the C part of the front end and the only reason why I don't check
them in directly is that it makes Arno's job harder when some changes from
the local tree are checked in and some aren't.
One of the powerful ways people learn is by reading the patch list,
*if* the patches follow our rules. A self-contained patch with an
explanation (and testcase if appropriate) is much easier to grok than
a sterile jumbo batch. You merely help maintain Ada's marginal status
by keeping everything cloistered and the expertise all within ACT.
"Self-contained" is not nearly as easy as you think. Ada is a quite large
language. GNAT has been around for over a decade. Although there are still
the occaisional "how did *that* ever work?" sort of bugs, most bugs found are
quite subtle and the amount of information needed to make their explanation
"self-contained" and understandable to people who aren't Ada experts is
Neither Robert, Arno, or myself are saying this is impossible. What I'm
saying is that the cost-benefit analysis of this is different from the
other front ends on both sides. On the one side, the benefit of doing
it is far less because there isn't a set of people out there who are
eager to learn all about Ada (it would be nice if there *were*, but let's
be realistic!). On the other, the cost is higher for the reasons
Also, "review" doesn't necessarily mean approve or reject. Someone
completely ignorant of Ada might simply catch a spelling mistake in a
Sure, but that can be done irrespective of whether they are one patch
or multiple in a message.
Having the proper patch submission helps for posterity in case anyone
needs to go back and examine it later. The fact that ACT may have
this information internally fails to help the rest of the world.
But the question, from a practical and realistic perspective, is whether this
information is really *useful* to the "rest of the world". Who would want to
use it and for what purpose? Before deciding to commit resources to
*produce* information, it's important to be sure there will be *consumers* of
that information. And I don't see that. The argument "if you make it, they
will come" doesn't seem that convincing to me in this case.
Lot's of contributors work for companies that have customers, none of
these customers use GCC head either. When their customers report bugs
against older versions of GCC, the patches are submitted correctly
according to our rules and tested on every branch they are installed.
Arno tests patches with the latest branch. And I test my patches to the C
part of the front end with the latest branch as well. The issue is the cost
of having *everybody* who develops front-end patches doing that as well.
You're talking about a dozen people here.