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: 101deb,baed328e88d400db X-Google-Attributes: gid101deb,public X-Google-Thread: 1014db,9d58048b8113c00f X-Google-Attributes: gid1014db,public X-Google-Thread: 10cc59,baed328e88d400db X-Google-Attributes: gid10cc59,public X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public From: adam@irvine.com (Adam Beneschan) Subject: Re: next "big" language?? (disagree) Date: 1996/06/18 Message-ID: <4q707h$1r2@krusty.irvine.com>#1/1 X-Deja-AN: 160892864 references: organization: /z/news/newsctl/organization newsgroups: comp.lang.pascal,comp.lang.c,comp.lang.misc,comp.lang.pl1,comp.lang.ada Date: 1996-06-18T00:00:00+00:00 List-Id: jsa@organon.com (Jon S Anthony) writes: >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. 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? -- Adam