Re: Ada95 Should be a Multivolume ISO Standard

[heatwole@his.com (Kevin D. Heatwole)]

In article <9610011027.AA12679@nile.gnat.com>, Robert Dewar
<dewar@GNAT.COM> wrote:
>This is an inaccurate characterization of my views. I am the CEO of one of
>the very few companies that is dedicated to the commercial success of Ada.
>My view are entirely motivated from a business point of view, I think
>a shifting standard for Ada, which involved the incorporation of inevitably
>less well reviewed extensions would be damaging from a business point of view.

As an employee of another small company which is pouring (or is that 
"pooring" :-)) its heart and sole into making a world-class Ada95 compiler, 
I wholeheartedly agree with Dr. Dewar on this one.  I have seen nothing yet 
that suggests that Ada95 is broken badly enough to require significant 
changes to the current standard.  Those few areas that are legitimately 
broken can and should be dealt with through the existing mechanism of 
issuing a binding AI to the standard and hopefully implementing an ACVC test 
to check for conformance by all validated Ada compilers to this binding AI.

To me, it is important that all commercially available Ada compilers 
implement the same language.  It doesn't seem to be in anybody's best 
interests to have each compiler implement some dialect of Ada95 just to 
make some person's program easier to write or to "fix" some part of the 
language that a specific compiler vendor feels is "broken".  I already have 
significant concerns that GNAT will implement such new tweaks to the 
language creating a bunch of GNAT-Ada code to be developed that won't 
easily be reuseable with other Ada compilers.

About 10 years ago, I spent around 3 months implementing a design on the 
Rational R1000 Environment.  All went very well on the Rational machine, 
but when I ported the code to the target machine (using an Alsys compiler), 
I found that the Alsys compiler caught an error in my use of generic formal
parameters. This error caused me significant effort and a major 
reimplementation to get around the error.  When I reported this bug to
Rational, the engineer commented that he knew about this incompatibility,
but that he felt that Ada was broken here and had chosen to implement a 
relaxation of the rules in this case. In other words, it was a conscious 
decision by a compiler vendor to allow a dialect of Ada into their compiler.
This cost my project some real dollars.

Anyway, as an Ada programmer, I can accept that no vendor's Ada compiler 
will accept all legal Ada programs and reject all illegal ones.  Ada is just 
to complex to expect a perfect compiler, but hopefully all vendors will make 
every effort to produce a perfect compiler.  Dribbling in potentially 
ill-thought out enhancements to the language is a sure formula to create a 
tower of Babel.

Note that I think it is perfectly legitimate for Ada compilers to implement
non-standard features for various reasons, but I hope the compiler vendor 
that choose to do so, will make it painfully obvious to the user that they are 
no longer writing Ada but some pigeon Ada dialect (like requiring the use of
a specific compiler switch to enable the dialect and hopefully generating
appropriate warnings for non-standard Ada uses).

Kevin Heatwole
OC Systems, Inc.