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: 10cc59,9d58048b8113c00f X-Google-Attributes: gid10cc59,public X-Google-Thread: 101deb,b20bb06b63f6e65 X-Google-Attributes: gid101deb,public X-Google-Thread: 1014db,9d58048b8113c00f X-Google-Attributes: gid1014db,public From: jsa@organon.com (Jon S Anthony) Subject: Re: next "big" language?? (disagree) Date: 1996/06/19 Message-ID: #1/1 X-Deja-AN: 161045597 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.pascal,comp.lang.c,comp.lang.misc,comp.lang.pl1,comp.lang.ada Date: 1996-06-19T00:00:00+00:00 List-Id: In article <4q707h$1r2@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes: > jsa@organon.com (Jon S Anthony) writes: > >In article dewar@cs.nyu.edu (Robert Dewar) writes: [...snip...] > >> When we discussed putting pragma Assert into the language (i.e. into the > >> standard), it was this point that tripped us up, and resulted in it being > >> left out. We could not figure out how to formally define the notion that > >> the compiler should NOT be allowed to use the assertion for optimization > >> purpoes. > > > >This is _almost_ as wog-boggling as the goof-up of not directly > >supporting specification of mutually recursive types across packages. > > > >Really. It is incomprehensible. I suppose these people don't want > >_any_ optimizations? No? Well, how do they justify all that > >"intrusive" code movement and elmination that happens with > >"standard/traditional" optimization? What about ranges? They can be > >seen in various contexts as just being a limited form of assertion. > >And those are taken advantage of all the time for "intrusive" > >optimizations. I suppose they positively have paroxysms over this. > > 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? Yes. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com