From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,61727075d20a4300 X-Google-Attributes: gid103376,public From: heatwole@his.com (Kevin D. Heatwole) Subject: Re: Ada95 Should be a Multivolume ISO Standard Date: 1996/10/01 Message-ID: #1/1 X-Deja-AN: 186466020 references: <9610011027.AA12679@nile.gnat.com> content-type: text/plain; charset=ISO-8859-1 organization: Heller Information Services, Inc. mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-10-01T00:00:00+00:00 List-Id: In article <9610011027.AA12679@nile.gnat.com>, Robert Dewar 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.