Reenabling Ada by default

[James A. Morrison]

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

 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.
 
> 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
> I've outlined.

 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.

>     Also, "review" doesn't necessarily mean approve or reject.  Someone
>     completely ignorant of Ada might simply catch a spelling mistake in a
>     comment.  
> 
> Sure, but that can be done irrespective of whether they are one patch
> or multiple in a message.

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

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

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

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

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

-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim