Reenabling Ada by default

[Robert Dewar]

James A. Morrison wrote:

> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> 
> 
>>    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.

Actually I disagree. And I would be interested on hearing from anyone
who has looked carefully at the GNAT front end. The GNAT front end
is remarkably well documented, and (we have a lot of experience in
this), the way people learn the front end of GNAT is by reading the
GNAT sources. It's something we routinely ask graduate students to
do at NYU, and we have many interns who in a couple of weeks can get
pretty fluent.

> I wouldn't mind seeing patches with some explanation.  Even if that
> explanation went way over my head, I may be able a term to two to look up and
> understand what has actually happened.

My goodness, ALL the GNAT front end patches come with
explanation. In fact we won't admit a patch to the sources
which does not come fully documented. If you think that large
piles of patches are being submitted that are undocumented,
I can pretty much guarantee that you have not looked at
them carefully. Not only do we insist on extensive source
documentation for all changes, but we also insist on
extensive revision histories that say *why* a change
was made, rather than just *what*.

>  Ok, there are less people wanting to learn every scary bit of Ada than say
> C++, but that isn't to say they don't exist.  I took a bit of time and looked
> at the dejagnu files in the gcc tree to see if I can add some dg style ada
> tests.  Unfortunatly, ada/ali.adb didn't compile during the bootstrap on
> ppc-linux.

Well we can routinely build ppc-linux GNAT from the current sources,
so something strange was going on. If you do want to know about GNAT,
I think you will find the sources pleasantly easy to get into.

Just to give an idea of how our internal review works, I look at
every modified front end file, and do a visual diff (using GPS).
I then examine the change and make sure it makes sense, and is
fully documented. I then check the RH to make sure that it is
complete. If either criterion is not followed, I "negotiate"
with the submitter. I then make minor style corrections where
appropriate. I do that once a day with the collected checkins
for the day, and it is a relatively easy process, precisely
because all changes are well documented.

> It's much easier to do one at a time with nice small inlined or test/plain
> patches than big gzipped patches.

Well as one who does spell checks and style checks every day,
I disagree, it is much easier to do these on an aggregated set
of of changes.

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

Actually you can follow the development and updates quite easily.
All the documentation is definitely available externally. What is
not available is the internal investigation of the bug, typically
involving a proprietary test case, but all the time I go back in
revision histories to understand prior changes.

I really encourage looking at some of the patches. I think that
some people are operating here with guesses as to what is there
that does not correspond to reality.

> Well, producing this information will at least be consumed by people reading
> gcc-patches.

I am not quite sure what information you are talking about here.
Short concise test cases would definitely be helpful, no argument
there, but I don't think they would add any information as such.

> A dozen people with more resources than a lot of the non-regular gcc
> contributors.

Not really, not in terms of having spare time to do non-customer
essential stuff. Time is at a premium here at AdaCore. If there
are other companies where programmers have lots of spare time,
that's definitely a luxury we do not share.