Re: LRM 11.6 changing behavior (was: Bug in AdaEd???)

Re: LRM 11.6 changing behavior (was: Bug in AdaEd???)

[Wes Groleau x1240 C73-8]

Give me a break!

  If I INTENDED to raise an exception, I would normally use a "raise"
statement. 

But it may not always be obvious to a programmer using objects
from another package or even someone else's work in the same unit, that
a particular statement will always raise a predefined statement.  But
even if he/she KNEW it, it is not reasonable for a compiler to NOT raise
the exception.  One of the many purposes of exceptions is to inform programmers
that they did something they shouldn't have.  Some people are now interpreting
LRM 11.6 to mean "If you do write code that the compiler vendor thinks you
shouldn't, the compiler vendor has the right to pretend you didn't." 
I normally try to avoid starting or encouraging flame wars, but I can't 
resist saying, "I don't believe the LRM writers intended anything so stupid."

Wes G.

Re: LRM 11.6 changing behavior (was: Bug in AdaEd???)

[david.c.willett]

>From article <CDt6zx.324@crdnns.crd.ge.com>, by groleau@e7sa.crd.ge.com (Wes G
roleau x1240 C73-8):
> Give me a break!
> 
>   If I INTENDED to raise an exception, I would normally use a "raise"
> statement. 
> 
> But it may not always be obvious to a programmer using objects
> from another package or even someone else's work in the same unit, that
> a particular statement will always raise a predefined statement.  But
> even if he/she KNEW it, it is not reasonable for a compiler to NOT raise
> the exception.  One of the many purposes of exceptions is to inform programme
rs
> that they did something they shouldn't have.  Some people are now interpretin
g
> LRM 11.6 to mean "If you do write code that the compiler vendor thinks you
> shouldn't, the compiler vendor has the right to pretend you didn't." 
> I normally try to avoid starting or encouraging flame wars, but I can't 
> resist saying, "I don't believe the LRM writers intended anything so stupid."
> 
> Wes G.

Consider that many documents, the US Constitution comes to mind, were 
interpreted by later "users" in ways their authors probably didn't imagine.
I haven' been following this thread, so you may be absolutely right, but 
the idea of compiler writers "loosely" interpreting the LRM doesn't seem
so far-fetched to me.

After all, what do we pay AJPO for?  

:^).....It's a joke folks, I'm only kidding..... :^)


<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dave Willett          AT&T Federal Systems Advanced Technologies

Remember Dave, you don't pay an anesthesiologist all that money to put you
to sleep, you pay him to wake you up afterwards!

	-- from a discussion on the value of medical specialists

Re: LRM 11.6 changing behavior (was: Bug in AdaEd???)

[Norm an H. Cohen]

In article <CDt6zx.324@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes
Groleau x1240 C73-8) writes: 

|> Give me a break!
|>
|>   If I INTENDED to raise an exception, I would normally use a "raise"
|> statement.

Good: That is precisely the programming style presumed by RM 11.6.
(11.6 does NOT allow raise statements to be optimized away, just certain
predefined operations and the checks associated with them.) In the case
of a predefined operation such as array indexing the presumption is that
your algorithm does not count on an exception being raised.  Of course
your algorithm counts on a bad index value not being used, but that's a
different matter.  If an optimizer eliminates the array indexing
operation, it can also eliminate the check that protected against bad
index values.

|> ... it is not reasonable for a compiler to NOT raise
|> the exception.  One of the many purposes of exceptions is to inform programm
ers
|> that they did something they shouldn't have.

In an application demanding high performance, it will not do to check
(for example) that an array indexing operation that is not being
performed (because its results are not needed) WOULD have used a valid
index value if it HAD been performed.

If we were to require Ada compilers to retain otherwise useless
predefined operations just to preserve the possibility of an exception
being raised, we would make it impossible for Ada compilers to perform
the same sorts of optimizations that are routinely performed by C and
FORTRAN compilers.  We would also make it impossible for an Ada compiler
front end to use the same optimizing back end that the front ends for
other languages use.  It is already hard enough to produce Ada compilers
that are competitive in both price and generated-code performance with
compilers for other languages.

There are lots of potential consistency checks (e.g.  assertion checks
for loop invariants, checks that variables have been initialized before
use, checks that deallocated variables are not used, etc.) that could
potentially be performed to assure the programmer or tester that the
program has not entered an unexpected state.  It is not a purpose of the
exception mechanism to ensure that all possible consistency checks are
performed.  A predefined exception is raised in situations where there is
no sensible way to continue normal computation.

If it is a requirement on your program to check that I is within A'Range,
you should code the check explicitly--

   if I not in A'Range then
      raise Self_Check_Failure;
   end if;

--rather than counting on a statement like

   Dummy := A(I);  -- No further use of Dummy

to perform the check implicitly.  (As your note said, if you INTEND to
raise an exception, you should use a raise statement.)

|>                                               Some people are now interpreti
ng
|> LRM 11.6 to mean "If you do write code that the compiler vendor thinks you
|> shouldn't, the compiler vendor has the right to pretend you didn't."

Not quite.  RM 11.6 says that if you write code that the compiler
determines not to affect the state of an exception-free computation, the
compiler has the right to pretend you didn't.  (I'm talking only about
exceptions raised by predefined operations here.)  The compiler is not
required to retain otherwise useless predefined operations just to
preserve the possibility that those operations might raise exceptions.

--
Norman H. Cohen    ncohen@watson.ibm.com