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,a3ca574fc2007430
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Ada and Automotive Industry
Date: 1996/12/11
Message-ID: <EACHUS.96Dec10195317@spectre.mitre.org>#1/1
X-Deja-AN: 203420404
references: <mazzanti-0512961053010001@131.114.200.115>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-12-11T00:00:00+00:00
List-Id: <comp.lang.ada>



  Franco Mazzanti said:

  > For Ada95, the numbering of "Ada Items" has clealry restarted from
  > 1, but it is not clear how many of the unresolved Ada 83 items
  > would be still applicable to Ada95 (hopefully a small number, but
  > definitively a number greater than zero).

  Robert Dewar said:

  > If there is an Ada 83 AI that is not considered and dealt with in quite
  > a deliberate manner in the Ada 95 RM, it is an oversight, and one that
  > I would be surprised to find ...

    True, but if all the issues behind AI-315 are ever resolved in my
lifetime, I'll be an old, old man. ;-) 

    This incidently is STRONGLY agreeing with Robert Dewar.  AI-315
was extensively discussed during the development of Ada 95, and the
area of concern significantly reduced.  AFAIK, no other programming
language standards committee has even considered the issue, so Ada is
way ahead.  The issue is best described as reasoning from
non-erroneousness.  When is it legal to change the order of operations
or do some computations at compile time, assuming that the program
does not raise a predefined exception, even if it changes
the--user-discoverable--state if an error does occur?  The Ada 95
rules are much better than in Ada 83, but there are still some corners
where it is hard for the user to force a guarentee that an error
(which is the intended effect for that input) will occur.

     And the (RM 11.6) rules in Ada 83 were not all that bad... I once
got a call from an implementer seeking advice.  She correctly
understood that the Ada 83 rules required an extra copy operation in
some circumstances, and wanted confirmation.  A couple hours later, I
called her back, and dictated a short Fortran program over the phone.
This allowed her to go to the powers that be and get permission to put
the change in the common code generator.  There were legal Fortran
programs on their hardware with no overflows where the change was
necessary to avoid generating junk results!

     Other than that, the only "unresolved" Ada 83 AIs are "study"
issues.  These were suggested improvements to the language many of
which were considered beyond the state of the art in 1983.  Some study
topics were folded into Ada 95, some are still outstanding.

     But again, the difference between Ada 95 and other languages is
in Ada's favor.  For example, there was over ten years spent on
developing standards for mathematical functions.  Seems like a simple
issue, until you look at the poor state of the practice when Ada 83
was standardized--many existing math libraries were lucky to get
six-digit accuracy on easy functions like sine.  The work of the NRG
and NUMWG resulted in four standards, was folded into Ada 95, and also
influenced the language-indepentent arithmetic standards.  In the
process several new and more accurate or faster algorithms were
developed for the elementary functions.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...