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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Software landmines (was: Why C++ is successful) Date: 1998/08/19 Message-ID: #1/1 X-Deja-AN: 382489108 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <6rd27s$ffi$1@nnrp1.dejanews.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-08-19T00:00:00+00:00 List-Id: adam@irvine.com wrote: : ... : Anyway, here's my main question: Is it desirable to expand the syntax of : "exit" to cover cases like this? I think it might be nice. I'm thinking that : code like this could look something like: : block_to_do_stuff: : begin : blah-blah-blah; : exit block_to_do_stuff when error-condition-1; : keep-going; : exit block_to_do_stuff when error-condition-2; : still-keep-going; : exit block_to_do_stuff when error-condition-3; : everythings-still-fine-keep-going; : etc. : end block_to_do_stuff; : I think one of the Ada 9X proposals actually had a feature like this, but : unfortunately it also changed the semantics of "exit" in a way that would : change the meanings of a lot of Ada 83 code. Probably, that's why it was : dropped from the final Ada 95 definition. The Ada 9x proposal was "upward consistent" in that it didn't change the meaning of any existing programs to a new legal meaning, but it did make some of them illegal (those that involved exits from blocks nested in loops, I believe). : ... But I think that the exit-block : feature in my example would be a very useful addition to the next version : of Ada. (I'd define it so that this use of "exit" requires a block name, : so that the semantics of "unnamed" exit statements are unchanged; that way, : there wouldn't be any upward compatibility problems.) We also considered this proposal. Basically, we couldn't find a "clean" solution that looked like it wasn't just an add-on rather than something built in from the beginning. Also, the problem being solved is relatively minor, and we had bigger fish to fry (mix those metaphors liberally, please). : So do the rest of you think it's a useful enough feature to consider adding : to Ada? If there were a solution that treated loops and blocks symmetrically, that would be nice. But a proposal that only allows exiting from unnamed loops, while disallowing exiting from unnamed blocks, is a kludge. I would prefer something which allowed an unnamed "exit" to be legal only if there were exactly one block or loop enclosing the point. If there were more than one, then the exit would have to be named. This way, adding another level of block or loop to an existing program with an unnamed exit would never result in an exit going to the wrong place, but it might result in the program becoming illegal. This avoids a kind of "Beaujolais" effect for unnamed exit statements (the "Beaujolais" effect is a case where adding or removing a declaration from a "used" package would change the meaning of a program from one legal interpretation to another -- Ada 95 doesn't have them, Ada 83 had very few (all obscure), "used" C++ namespaces have them for sure). The general Ada principle is to require that the programmer write more if that will help to make the meaning clear to the reader. (Note that sometimes writing *less* makes things clearer to the reader. The key is to keep the signal to noise ratio high.) Unnamed exits should be limited to cases where there is no ambiguity, especially if they can exit multiple kinds of constructs. The C situation is bad news, where a "break" is used to exit both switch and loop, and there is no "named" version of it. I have seen plenty of bugs where a break was meant to exit a loop, but really only exited the nearest enclosing switch, or vice-versa. : -- Adam -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company