Reenabling Ada by default

[Robert Dewar]

Eric Christopher wrote:

>>I would say that this last criterion is clearly impossible. Large sections
>>of the front end assume intimate familiar with the Ada RM, and understanding
>>patches for the front end must almost always assume a pretty deep level of
>>Ada knowledge. However, I am not clear that ZW was making this request.
>>It would make no sense, so I really did not assume that this was the
>>intent. For example, any of the patches for implementing Ada 2005
>>features assumes complete familiarity with the (often very complex)
>>corresponding AI, and the AI itself generally assumes complete
>>familiarity with the RM.
> 
> 
> If it is, as you say, impossible to do public development of ada in the
> gcc source tree then why don't we remove it?

First let me say that I quoted these two paragraphs because
I don't see that the second flows from the first at all.
Public development of an Ada front end in any context
requires intimate knowledge of the Ada standard. The same
can be said for any language front end. People don't work
on a C++ compiler if they don't know C++ (or at least they
shouldn't, it seems to me that the price of admission for
a compiler writer writing a front end for language X is to
be familiar with language X). So my insistence that if you
want to play in the front end of the Ada compiler you need
to know Ada says nothing about whether or not it is possible
to do public development of Ada in the GCC source tree.

In fact if you want to look at any of the front end patches,
and if you *do* know the Ada standard (and relevant AI's)
well, you should find them quite easy to understand, since
they are very well documented. However, the group of people
that meet this criterion is small (and most of them work
for AdaCore, and most of the rest work for AdaCore's
competitors :-)

But going back to the second para above, even if I don't
understand it as a response to the quoted paragraph from
me ...

 > If it is, as you say, impossible to do public development of ada in the
 > gcc source tree

I said nothing of the kind, I merely said that if you want
to play in the Ada front end arena, you have to know Ada.
By the way, only a few people at AdaCore know enough to
work on the front end, it's a relatively small part of
our overall technology.

 > then why don't we remove it?

Well certainly we could, and probably from a purely commercial
point of view, that would be overall in AdaCore's commercial
interest. However, there are a lot of Ada users who have found
it very valuable to have Ada in the FSF tree, which is why we
make the effort of trying to keep it up to date. Take for
example the Tree-SSA work. We don't anticipate making a customer
release of GNAT Pro with Tree-SSA for a couple of years, since
our release cycle is slow and very conservative, but it is
definitely useful and interesting to the gcc ada community
to have this working, which is why Richard has been treating
it as a much more urgent project.

There are really two issues here

1. Having Ada present certainly carries advantages to Ada
users, and disadvantages to developers who have to worry
about it (the same is true of any front end). Of course
in this list we primarily see the discussion of developers
rather than users, so the proper balance may be tricky
to achieve.

2. With respect to the Ada front end patches, if we want
to keep up to date with the GNAT Pro tree, then we there
is the issue of the form in which these patches are done.
I consider this issue essentially orthogonal to issue 1.
That is, I don't think that the form of the front end
patches has any significant impact on how easy or how
difficult it is to deal with the balances of issue 1.
To me it is not particularly constructive to say that
the procedure for Ada front end patches must match that
of the C++ front end, since they are radically different
cases (in the case of the C++ front end, knowledge of
C++ is widely spread across the gcc development
community). What would be constructive would be to
understand exactly what is wanted and why.

If the front end patches are indeed causing difficulties
for developers, we could simply stop doing these patches
and leave the GNAT front end in its current state, fixing
only selected serious errors, and for example not bother
with the extensive Ada 2005 patches. That's certainly
less drastic than removing the GNAT front end entirely.