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,baed328e88d400db,start X-Google-Attributes: gid10cc59,public X-Google-Thread: 101deb,baed328e88d400db,start 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/15 Message-ID: #1/1 X-Deja-AN: 160379632 sender: news@organon.com (news) references: <4p1l65$35qi@info4.rus.uni-stuttgart.de> organization: Organon Motives, Inc. newsgroups: comp.lang.pascal,comp.lang.c,comp.lang.misc,comp.lang.pl1,comp.lang.ada Date: 1996-06-15T00:00:00+00:00 List-Id: In article dewar@cs.nyu.edu (Robert Dewar) writes: > A. Grant said > > "The point of assertions is not to print messages for the > programmer. You can use them to allow the compiler to > optimise safely, provide a contractual interface between > modules, and for preconditions, postconditions, loop invariants > etc. when proving the correctness of programs." > > Actually that is a very controversial statement. What most people want is > non-intrusive assertions that do NOT affect the generated code. That's > not 100% possible, but it is something you can aim at. > > It is certainly true that assertions can be used for compiler optimization, > but that's not what people want. That may be what _some_ people don't want. For reasons that would seem to be beyond the ken of mere mortals. But I would certainly hope that an Eiffel compiler, for example, would use the assertions specified by a programmer to (among other things) get rid of extraneous and useless code whenever it could deduce such cases from the assertions. What's the point of generating code for something that you _know_ won't be needed? that you _know_ will do _nothing_ but a) slow down execution speed and b) increase size of code? If these people like that sort of thing, how about just telling them to use the nooptimize pragma or switch? Then they can get all the useless code they want. > 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. Or, how about telling these people to _NOT_ use pragma assert if they are so wigged out about possibly useful optimizations? It's not like they are in any better shape now given the way things turned out. And the rest of us could be taking advantage of this without resorting to _NON_standard pragma Assert in GNAT. Or will this actually just become the defacto standard because it so obviously makes sense? Does the Intermetrics frontend implement Assert as defined in GNAT? Actually, the more I think about it, I believe this may be _more_ incomprehensible than the recursive type bungle after all. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com