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: f891f,9d58048b8113c00f
X-Google-Attributes: gidf891f,public
X-Google-Thread: 103376,2e71cf22768a124d
X-Google-Attributes: gid103376,public
X-Google-Thread: 101deb,b20bb06b63f6e65
X-Google-Attributes: gid101deb,public
X-Google-Thread: 10cc59,9d58048b8113c00f
X-Google-Attributes: gid10cc59,public
X-Google-Thread: 1014db,9d58048b8113c00f
X-Google-Attributes: gid1014db,public
From: adam@irvine.com (Adam Beneschan)
Subject: Re: next "big" language?? (disagree)
Date: 1996/06/24
Message-ID: <4qmqo3$suu@krusty.irvine.com>#1/1
X-Deja-AN: 161898996
references: <4q707h$1r2@krusty.irvine.com> <JSA.96Jun19115535@organon.com>
 <dewar.835306677@schonberg>
organization: /z/news/newsctl/organization
newsgroups: 
 comp.lang.pascal,comp.lang.c,comp.lang.misc,comp.lang.pl1,comp.lang.ada
Date: 1996-06-24T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.835306677@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
 >Jon said
 >
 >"I have to agree with Jon's point here.  I don't see any reason why the
 >definition of the language would have to prevent the compiler from
 >using the information for optimization.  If the customer didn't want
 >that to happen, the vendor could add a command-line option or pragma
 >to tell the compiler not to.  Don't Ada compilers already have
 >command-line options and/or pragmas to control how much optimization
 >takes place, anyway?"
 
The above words were mine, not Jon's.

 >This is really quite a tricky and subtle issue. If you do not see any
 >problem, then it is likely you don't see the issues fully yet. The basic
 >problem is that the notion of assertion can mean many things, and at the
 >level of discussing the precise semantics of assertions, there are
 >fundamental disagreements. There is certainly a school of thought that
 >is insistent that it is crucial that assertions NOT affect the semantics
 >or even the behavior of the program. 
 >
 >You can declare this silly if you like, but it is more helpful if everyone
 >makes the effort to understand the issues.
 >
 >In GNAT, 
 >
 >   pragma Assert (X);
 >
 >means EXACTLY
 >
 >   if not X then
 >	raise Assert_Error;
 >   end if;
 >
 >which is well defined, but not at all in the category of assertions that
 >the compiler can take advantage of, which can behave in a completely
 >differrent (and possibly suprising manner).

I'm losing you here.  What do you mean that the compiler can't take
advantage of the assertion?  If you mean simply that this is how GNAT
has been taught to behave, OK--you know a lot more about GNAT than I
do. 

If you mean that logically or semantically, the compiler can't take
advantage of the information--why not?  If I wrote code that looked
like this:

      if X not in Some_Subtype'range then
          raise Some_User_Defined_Error;
      end if;
      
  {    . . . More code that doesn't modify X . . .
  {    if X < Some_Subtype'first then
  {        blahblahblah
  {    end if;

I would expect a good optimizer to assume, throughout the bracketed
section of code, that X was in Some_Subtype'range, because control
could never get to that part of the code if it weren't.  (Assuming, of
course, X is not volatile.)  Therefore, the second "if" statement
could be deleted, and any other checks that made sure X was in
Some_Subtype'range could be suppressed.  

And if I'd expect this behavior if an exception I defined were raised,
why would I not expect this if the "raise" statement were changed to
raise Assert_Error?

(I could be missing the whole point of this thread--it's gone on for a
while and I've forgotten how it started.)

                                -- Adam