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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,99e73f65ea2533b9 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!news.osn.de!diablo2.news.osn.de!newsfeed0.kamp.net!newsfeed.kamp.net!newsfeed.freenet.de!news2.euro.net!postnews2.euro.net!news.euronet.nl!not-for-mail From: "Karel Th�nissen" Newsgroups: comp.lang.ada References: <18b41828-bda4-4484-8884-ad62ce1c831d@f36g2000hsa.googlegroups.com> <57qdnfULQ9tzKCHVnZ2dnUVZ_tHinZ2d@comcast.com> <48bd0003$1@news.post.ch> <48bf90bf$0$30032$dbd4d001@news.euronet.nl> Subject: Re: and then... (a curiosity) Date: Thu, 4 Sep 2008 17:16:05 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-RFC2646: Format=Flowed; Original Message-ID: <48bffbb7$0$74166$dbd49001@news.euronet.nl> Organization: EuroNet Internet NNTP-Posting-Date: 04 Sep 2008 15:16:07 GMT NNTP-Posting-Host: ht-c-98a0.mxs.adsl.euronet.nl X-Trace: 1220541367 dr7.euro.net 74166 62.234.184.160:2753 X-Complaints-To: abuse@euronet.nl Xref: g2news2.google.com comp.lang.ada:7644 Date: 2008-09-04T15:16:07+00:00 List-Id: schreef in bericht news:Pine.LNX.4.64.0809041404570.22581@medsec1.medien.uni-weimar.de... >> > Thus, "if X/=0 and Y/X<100" should go into the else-branch, instead of >> > raising an exception. >> > The shortcut version "if X/=0 and then Y/X<100" does exactly the right >> > thing. >> That would be a very bad idea. With that in place, an exception raised by >> a >> simple programming error, /any/ programming error, would give control to >> the >> else-branch. > You misread what I wrote. A statement such as "if Y/X<000" should > definitively propagate an exception for X=0, and I never said anything > otherwise. So if I understand you correctly this time, the raising (or not) of an exception for "if Y/X<000" should in your view depend on the context where it is used: /do not raise/ inside branching conditions of a certain pattern, but /do raise/ when used as an ordinary statement. I fear that you underestimate the complexities of putting that smartness in a compiler and you overestimate the abilities of the ordinary programmers to understand what is going on. No, I do not think I misread. Your writing was not precise: you wrote "if X/=0 and Y/X<100" should go into the else-branch, instead of raising an exception. But in Ada it does not go to the else-branche for X=0. So you are proposing a language change, and I point out that that would be a vey bad idea. We cannot expect the compiler to be so smart to distinguish exceptions that are avoidable if the left operand had been evaluated first (as with conditional boolean operators) from the other exceptions in general. So the only viable options are: not doing it like this at all (my choice) or picking the else branche for all exceptions. That would make it in invisible exception handler. Bad, bad, bad. And as noted above, it would also introduce context sensitivity whether exceptions should be raised or not. Again very bad. And if you do want conditional evaluation, you choose 'and then'. What is wrong with it? Okay, it is wordy, but the formantics in Ada are very precise. That is more important than 5 characters saved. Maybe you meant 'and' in your example in a more abstract sense without providing the precision is demanded by Ada. Unfortunately, you expressed it as valid Ada. > But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas, > done in Ada, something is logically wrong. So you do think that it should not raise an exception and go to the else-branche????? Now what do you want? You contradict yourself. Or this the reason you came up with the context dependent interpretation of source code? The problem is probably that you use the words 'and' and 'should' in two different ways. Seems to be the whole point of this discussion. How much intelligence do you expect from a compiler? And even if the compiler where that smart, would we mere programmers understand what was going on. How smart should the compiler be? Should it also start using inference, perhaps using whole program analysis? Computing just is not standard logic. Simple boolean logic will not help us out and we should stop looking at mathematics and logic as the holy grail in computing. It is a different subject. > BTW, why do you think that an exception, such as a Constraint_Error, > should logically count as a contradiction? > > Dividing something by zero is undefined, not a contradiction. That again shows my point that mathematics and computing are two different beasts. A mathematician will put the pencil done and stop immediately when asked to do an undefined operation, such as a division by zero. That just is not an option if you are flying 1000 km/h. Then you raise an exception and try to make the best of it, probably working from an unknown or even corrupted state, regaining control over the machine and bringing the passengers to safety. If the mathematician were to continue anyway and tried to find his way out like our software, he could easily obtain contradicitonary results. This should be compared with invariants that are broken because of the reaching of an undefined operation/ raising an exception in software. Comparing undefined/raising an exception allowed because they share the property: that the result is neither true nor false: false AND raisingAnException => raisingAnException false AND contradictionary => contradictionary Remember that I introduced this point about contradictions where someone (you?) equated ternary logic with Kleene's logic. There are other ternary logics. Just to be nitpicking: coming from a DbC-background, a division by zero should raise a *violation* of contract, not an exception. A violation indeed is a contraction with the explicitly stated contracts. After a violation anything goes. *Exceptions* should be used for things that can be expected, but that should be very rare and that are to hard to handle using standard control structures. Think of printers that break down, or network failures. Groeten, Karel