From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,RISK_FREE
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 21 Jan 91 15:11:03 GMT
From: sei!ae@tut.cis.ohio-state.edu  (Arthur Evans)
Subject: Stability for Embedded Applications?
Message-ID: <10154@as0c.sei.cmu.edu>
List-Id: <comp.lang.ada>

Jean Pierre Rosen (rosen@meduse.enst.fr) says
> There is only one Ada language, and all versions of the ACVC test this
> same language; 1.11 has just more tests than 1.10.  No other language
> is so strictely controlled, so uniform, so validated or has so many
> compilers second sources. It does not mean there is no risk for the
> future: it just means that the risks are order of magnitude lower than
> with any other language.

All true, but, unfortunately, that doesn't tell the whole story.  Ada 83
has many places where the definition leaves matters up to the discretion
of the implementor.  The idea was not to tie the implementors' hands but
to give them flexibility to achieve maximum possible efficiency.

Now, an Ada user is surely taking risks in writing code that depends on
how the compiler happens to implement one of these freedoms.  However,
in the rush of getting the code written, real programmers will test the
compiler, find that it does such-and-such, and then write code that
takes advantage of that behavior.  Neither higher management nor
documentation is likely to know of such decisions.  Yes, we know that's
bad.  And yes, it surely happens.

When the vendor issues a new release, it may well implement such
decisions differently.  Thus code that worked before may stop working,
and this situation is both legal and consistent with ACVCs.  This is the
long term stability problem raised by the original poster on this
subject.

Now, don't get me wrong.  Ada is probably vastly less susceptible to
this problem than any other contender in the market place.  But Ada is
not perfect, and none of us should pretend that it is.

This problem has attracted much attention in the Ada 9X Requirements
process, and the Requirements Document encourages the Mapping/Revision
Team to eliminate as many implementation freedoms as possible.  That's
surely good.  However, every implementation freedom eliminated in 9X
represents a lack of upward compatability for folks whose code happens
to take advantage of such freedom, and these folks will surely get
burned.  The Requirements Team, with the support of the Distinguished
Reviewers, concluded that this was the best long-term solution for Ada.

The pertinent provision of the Requirement Document is from Section 1.4
on General Guidelines:

  - Upward Compatibility: In general, any legal Ada 83 program must also
    be a legal Ada 9X program and must have the same effect allowed or
    required by Ada 83.  However, to improve the portability of Ada
    programs, and to satisfy other requirements, it may be necessary to
    eliminate some effects allowed by Ada 83 or to make some Ada 83
    programs illegal.  In these cases, the following guidelines shall
    apply:

     - No implementation-dependent behavior allowed in Ada 83 shall be
       excluded in Ada 9X if that behavior is actually supported by a
       significant number of implementations and is important to a
       significant number of users.

     - No Ada 83 program shall be illegal in Ada 9X unless it is
       relatively easy to correct the illegal program or it is expected
       that very few existing legal programs will be affected (since the
       programs are either pathological or erroneous).

     - No legal Ada 83 program shall have a different semantic effect in
       Ada 9X unless it is expected that extremely few existing programs
       will be affected (e.g., it might be acceptable to modify the
       optimization rules in ways that affect when the evaluation of an
       expression requires CONSTRAINT_ERROR or NUMERIC_ERROR to be
       raised).

    Any non-upward-compatible changes shall be justified by the
    Mapping/Revision Team and where possible, accompanied by an analysis
    of techniques for detecting possible incompatibilities in existing
    programs.

Art Evans
Software Engineering Institute
Carnegie Mellon University