Re: Ada and Automotive Industry

Re: Ada and Automotive Industry

[Franco Mazzanti]

> 
> In article <HtgbhGAHr1oyEwD5@phaedsys.demon.co.uk> Chris Hills
<chris@phaedsys.demon.co.uk> writes:
> 
> > >I am amused by the number "2000".  There are, in fact, 174 "Ada Issues",
> > >which are the rulings, or pending rulings, on the current Ada standard.
> > >Of these, 69 are considered bugs in the Standard document.  (Others are
> > >editorial comments, cases where the question has an obvious answer, and
> > >so forth).
> > >

Just for giving an exlanation of the 2000 magic number, which some time
to time appears in articles and talks.

This number is mentioned in the book "Safer C" by Les Hatton (bottom of
page 187) during a comparison a C vs. Ada. The number is clearly related
to Ada83 (since the book was published in 1994) and, even if the number is

probably too large, at least the order of magnitude is quite correct.

More precisely, 1442 comments have been formnally submitted for Ada83, and 
these resulted in 903  "Ada Items".
(see ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/83com/ai-index.toc)

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

Franco Mazzanti

Re: Ada and Automotive Industry

[Robert Dewar]

Franco 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)."

What makes you think this? Part of the design work on Ada 95 required
careful consideration of every Ada 83 AI (rememebvr that there are 
nowhere near 1500 real AI's, many of these are presentation issues,
e.g. commas in the wrong type font).

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

Re: Ada and Automotive Industry

[Robert I. Eachus]

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

Re: Ada and Automotive Industry

[Ted Dennison]

Robert I. Eachus wrote:
> 
> 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.

Hmmm. Can I take this to mean that it is not a good idea to raise
predefined exceptions manually? Are predefined exceptions somehow
handled differently than user-defined ones?

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[Robert Dewar]

T.E.D. says

"Hmmm. Can I take this to mean that it is not a good idea to raise
predefined exceptions manually? Are predefined exceptions somehow
handled differently than user-defined ones?"


Yes, see RM 11.6
\x1adp

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <32B197A6.2781E494@escmail.orl.lmco.com> Ted Dennison <dennison@escmail.orl.lmco.com> writes:

 > Hmmm. Can I take this to mean that it is not a good idea to raise
 > predefined exceptions manually? Are predefined exceptions somehow
 > handled differently than user-defined ones?


   I'll answer this in reverse order.  The Ada 95 11.6 allows the
optimization of language defined checks, not explicit raise
statements.  However, you can have situations where the failure of a
languagge defined check will cause an explicit raise statement to be
invoked:

   begin
     Foo := new Bar(A*B); --allocate A*B bytes.
   exception
     when others => raise Storage_Error;
     -- if A*B overflows, raise Storage_Error anyway.
   end;

   If Foo is never used, it is legal to optimize away the allocation,
whether the handler raises Storage_Error or Fubar.  For this reason I
prefer to explicitly raise a predefined exception when the raise can
get optimized away like this.

   So my rule on explicitly raising predefined exceptions is that I
will raise them either if the meaning is the predefined meaning of
that exception, or if suppression of a language defined check, either
explicitly or through 11.6, will potentially suppress the exception.

--

					Robert I. Eachus

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

Re: Ada and Automotive Industry

[Tucker Taft]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: T.E.D. says

: "Hmmm. Can I take this to mean that it is not a good idea to raise
: predefined exceptions manually? Are predefined exceptions somehow
: handled differently than user-defined ones?"


: Yes, see RM 11.6

Hmmm...  Language-defined *checks* (which can raise predefined exceptions)
are handled specially.  In particularly, they need not raise an exception
at all if the otherwise "undefined" result would not be used by the
rest of the computation, and if they are raised due to the failure
of such a check, the "location" of the raise need not be precisely
determinable.

However, when an exception is raised explicitly, it makes no
difference whether it is predefined or user-defined -- the
rules are identical.  

Of course, once you get to a handler for a predefined exception, you don't
know as much since it might be due to a failure of a language
defined check (and hence might be imprecise), or it might be due to 
an explicit "raise" (in which case it is fully "precise").

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Ada and Automotive Industry

[Robert Dewar]

Bob Duff said

"Just to clarify: 11.6 applies only to language-defined checks, not
explicit raise statements like "raise Constraint_Error;".  But I agree
with Robert that "raise Constraint_Error;" is unlikely to be a good idea
in most cases."


I disagree. It is often quite appropriate. Suppose you wrote a little
package for giving saturation type semantics on ordinary arithmetic
(overflow transfomed to max or min value as appropraite). You might
still very well want to diagnose division by zero as an error, and
raising constraint error would seem a perfectly good way of doing it.

Re: Ada and Automotive Industry

[Robert A Duff]

In article <dewar.850929677@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I disagree. It is often quite appropriate. Suppose you wrote a little
>package for giving saturation type semantics on ordinary arithmetic
>(overflow transfomed to max or min value as appropraite). You might
>still very well want to diagnose division by zero as an error, and
>raising constraint error would seem a perfectly good way of doing it.

OK, I'll buy that.  How about the following rule of thumb: It's OK to
raise C_E explicitly if the purpose is to indicate a bug in the program?
That is, if the exception occurs, you want the program to stop running,
not do any more damage, and go into the debugger and figure out what
went wrong (or use a stack traceback or whatever).  On the other hand,
if you want callers to *handle* the exception, and recover from it, you
ought to define your own exception name.

My reasoning is that handlers for C_E are questionable -- you probably
don't know for sure whether you got there from a range check, or your
explicit raise, so you have to worry about 11.6 issues.  It's possible,
but extremely tricky, to write correct exception handlers for C_E, given
11.6.  I suspect that few programmers understand 11.6 -- they just use a
simplified rule, which says "Don't handle C_E".  That's good -- it's
much simpler than the real 11.6 rules, and works fine in the vast
majority of cases.

(By the way, when I say "handle" here, I mean a handler that really
handles the situation -- not one that does clean-up-then-re-raise.)

So, in your divide-by-zero example, it seems fine to raise C_E, if you
believe that exception will always kill the program, if it happens.

- Bob

Re: Ada and Automotive Industry

[Ken Garlington]

Robert A Duff wrote:
> 
> OK, I'll buy that.  How about the following rule of thumb: It's OK to
> raise C_E explicitly if the purpose is to indicate a bug in the program?

Actually, I like to raise Program_Error when this happens. Its' roughly
equivalent to the "WTF?" message we used to generate in our FORTRAN
tools
when we reached a condition in the program that "shouldn't happen."

> That is, if the exception occurs, you want the program to stop running,
> not do any more damage, and go into the debugger and figure out what
> went wrong (or use a stack traceback or whatever).  On the other hand,
> if you want callers to *handle* the exception, and recover from it, you
> ought to define your own exception name.
> 
> My reasoning is that handlers for C_E are questionable -- you probably
> don't know for sure whether you got there from a range check, or your
> explicit raise, so you have to worry about 11.6 issues.  It's possible,
> but extremely tricky, to write correct exception handlers for C_E, given
> 11.6.  I suspect that few programmers understand 11.6 -- they just use a
> simplified rule, which says "Don't handle C_E".  That's good -- it's
> much simpler than the real 11.6 rules, and works fine in the vast
> majority of cases.
> 
> (By the way, when I say "handle" here, I mean a handler that really
> handles the situation -- not one that does clean-up-then-re-raise.)
> 
> So, in your divide-by-zero example, it seems fine to raise C_E, if you
> believe that exception will always kill the program, if it happens.
> 
> - Bob

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Ada and Automotive Industry

[Robert A Duff]

In article <dewar.850626633@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>T.E.D. says
>
>"Hmmm. Can I take this to mean that it is not a good idea to raise
>predefined exceptions manually? Are predefined exceptions somehow
>handled differently than user-defined ones?"
>
>Yes, see RM 11.6

Just to clarify: 11.6 applies only to language-defined checks, not
explicit raise statements like "raise Constraint_Error;".  But I agree
with Robert that "raise Constraint_Error;" is unlikely to be a good idea
in most cases.

- Bob

Re: Ada and Automotive Industry

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

   "Hmmm. Can I take this to mean that it is not a good idea to raise
   predefined exceptions manually? Are predefined exceptions somehow
   handled differently than user-defined ones?"

   Yes, see RM 11.6

RM 11.6 says nothing about raising language-defined exceptions.
It only specifies the behavior of language-defined *checks*.
I don't see why predefined exceptions are handled differently 
than user-defined ones.

   Geert
-- 
E-Mail: geert@sun3.iaf.nl : Die Windows is hartstikke vaag man, daar moeten 
                          : we een glazenwasser bij halen! (Meneer Jos) 

Re: Ada and Automotive Industry

[Keith Thompson]

In <dewar.850626633@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> T.E.D. says
> "Hmmm. Can I take this to mean that it is not a good idea to raise
> predefined exceptions manually? Are predefined exceptions somehow
> handled differently than user-defined ones?"
> 
> Yes, see RM 11.6

But 11.6 refers only to exceptions raised by predefined checks.
A predefined exception raised "manually" by an explicit raise statement
(or by a call to Ada.Exceptions.Raise_Exception) is semantically no
different than a user-defined exception raised the same way.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: Ada and Automotive Industry

[Keith Thompson]

In <E2LH08.72n@thomsoft.com> I wrote:
> A predefined exception raised "manually" by an explicit raise statement
> (or by a call to Ada.Exceptions.Raise_Exception) is semantically no
> different than a user-defined exception raised the same way.

This doesn't mean that explicitly raising predefined exceptions
is necessarily a good idea stylistically.  Unless the code you're
writing is intended to closely mimic some feature of the language, it's
usually clearer to declare and raise your own exception than to raise
a predefined one.  Some would say that there are far too many possible
sources of Constraint_Error already, for example.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: Ada and Automotive Industry

[Robert A Duff]

In article <32B8AF89.CA@lmtas.lmco.com>,
Ken Garlington  <GarlingtonKE@lmtas.lmco.com> wrote:
>Actually, I like to raise Program_Error when this happens. Its' roughly
>equivalent to the "WTF?" message we used to generate in our FORTRAN
>tools
>when we reached a condition in the program that "shouldn't happen."

Fine, but Robert Dewar's example was divide-by-zero in a user-defined
arithmetic package, and his point was that this divide-by-zero is
analogous to the predefined divide-by-zero, so C_E makes sense.  I
suspect Robert would extend that reasoning to say that C_E makes sense
whenever the error is conceptually "violating a constraint".  P_E
doesn't make much sense for divide by zero.

- Bob

Re: When to raise predefined exceptions (was: Ada and the Automotive Industry)

[James Rogers]

Ted Dennison wrote:

> I guess that is what I was getting at. There have been times where I
> wanted to consider certian values out of range for a type, but the only
> way to do it was to explicitly check for those values. It seemed
> pointless to create a new exception to raise, when any reasonable
> handler for this situation would just have to handle *both*
> Constraint_Error and my new exception.
>

I see your point, however it is possible to design away this
problem by handling CE in the subprogram in which it is raised by
raising your new exception.  This way calling subprograms would only
encounter your new exception.  If you use Ada.Exceptions you can
indicate what really happened in the Exception_Information string.
The handler for your new exception could direct its behavior based
upon both the exception name and the exception information, if such
fine control were deemed necessary.

-- 
Jim Rogers
*************************************************************
Team Ada

Re: Ada and Automotive Industry

[Philip Brashear]

With regard to explicitly raising predefined exceptions:

I can't really imagine when this would be appropriate.  If I write code that
detects an exceptional situation, then I should send a message (to the caller,
which might be the outside world) that identifies that situation, not one that
can be lost in the myriad of causes for predefined exceptions.  Therefore (I
teach my Ada students and require of my programmers), if the programmer knows
of an exceptional situation, s/he should provide and raise an exception that
will be visible to the unit invoking his/her code.

Phil Brashear
CTA INCORPORATED
(University of Dayton, sometimes)

When to raise predefined exceptions (was: Ada and the Automotive Industry)

[Ted Dennison]

Robert I. Eachus wrote:
> 
>    So my rule on explicitly raising predefined exceptions is that I
> will raise them either if the meaning is the predefined meaning of
> that exception, or if suppression of a language defined check, either
> explicitly or through 11.6, will potentially suppress the exception.

I guess that is what I was getting at. There have been times where I
wanted to consider certian values out of range for a type, but the only
way to do it was to explicitly check for those values. It seemed
pointless to create a new exception to raise, when any reasonable
handler for this situation would just have to handle *both*
Constraint_Error and my new exception.

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[Robert Dewar]

Phil said

"I can't really imagine when this would be appropriate.  If I write code that
detects an exceptional situation, then I should send a message (to the caller,
which might be the outside world) that identifies that situation, not one that
can be lost in the myriad of causes for predefined exceptions.  Therefore (I
teach my Ada students and require of my programmers), if the programmer knows
of an exceptional situation, s/he should provide and raise an exception that
will be visible to the unit invoking his/her code."

Are you up to date on this thread, or reading behind? If the former, then
why do you not agree with my (to me) perfectly reasonable example of a case
when it would be appropriate to raise constraint error (division by zero
in a package for implementing saturated arithmetic).

Re: When to raise predefined exceptions (was: Ada and the Automotive Industry)

[Robert Dewar]

Jim Rogers said

"I see your point, however it is possible to design away this
problem by handling CE in the subprogram in which it is raised by
raising your new exception.  This way calling subprograms would only
encounter your new exception.  If you use Ada.Exceptions you can
indicate what really happened in the Exception_Information string.
"


You mean Exception_Message here ....

Re: Ada and Automotive Industry

[Robert Dewar]

Ken says

"Actually, I like to raise Program_Error when this happens. Its' roughly
equivalent to the "WTF?" message we used to generate in our FORTRAN
tools
when we reached a condition in the program that "shouldn't happen.""



I prefer to make the distinction that the RM makes. Program_Error is raised
for logic errors in your program, which should never occur. Constraint_Error
is raised for an incorrect value that is outside the domain or range of
a basic operation.

It is of course true that this is not a well defined sharp line!

Re: Ada and Automotive Industry

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken says
> 
> "Actually, I like to raise Program_Error when this happens. Its' roughly
> equivalent to the "WTF?" message we used to generate in our FORTRAN
> tools
> when we reached a condition in the program that "shouldn't happen.""
> 
> I prefer to make the distinction that the RM makes. Program_Error is raised
> for logic errors in your program, which should never occur. Constraint_Error
> is raised for an incorrect value that is outside the domain or range of
> a basic operation.

Certainly. (I didn't get to see the original message, stating that the
error
in question was a Constraint_Error.)

In any case, I don't see any problem with raising pre-defined
exceptions, assuming:

1. The error is consistent with the definition in the RM, and
2. It's something that should be propagated instead of handled.

> 
> It is of course true that this is not a well defined sharp line!

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com