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!news4.google.com!feeder3.cambrium.nl!feeder4.cambrium.nl!feed.tweaknews.nl!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> <48bffbb7$0$74166$dbd49001@news.euronet.nl> Subject: Re: and then... (a curiosity) Date: Thu, 4 Sep 2008 22:06:41 +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: <48c03fd1$0$12199$dbd4f001@news.euronet.nl> Organization: EuroNet Internet NNTP-Posting-Date: 04 Sep 2008 20:06:41 GMT NNTP-Posting-Host: ht-c-98a0.mxs.adsl.euronet.nl X-Trace: 1220558801 dr4.euro.net 12199 62.234.184.160:3328 X-Complaints-To: abuse@euronet.nl Xref: g2news2.google.com comp.lang.ada:7653 Date: 2008-09-04T20:06:41+00:00 List-Id: > On Thu, 4 Sep 2008, stefan-lucks@see-the.signature wrote: > >> On Thu, 4 Sep 2008, wrote: >> > 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: [...] >> >> No, you misread me again. If you had read some earlier posts from me in >> this thread, what I am trying to express is that "and" should better do >> what "and then" actually does. That is it, so simple! If that /were the only thing you wrote/, then it would indeed be simple. But in your earlier posting, /and/ a few lines down in the very post I am replying to now (as a quote from an earlier posting), you write something different. See few lines further down. I personally could life with the idea that in Ada, 'and' would have had conditional formantics (now and-then)and some other operator would have unconditional formantics (now and). That is just swapping tokens at the lexical level. Fine. What is your point? > To be precise, here is a cut-and-paste from what I wrote in another > posting: > > 1. If the A- or the B-part in "if A and B" raises an exception, but the > other part is false, the "right thing" (TM) to do would be to transfer > control to the else clause (or below "end if", when there is no else). > The intermediate result can be viewed as a three-valued logic > expression, but the final outcome of the Boolean expression must be > Boolean, of course. Thank you, there it is. Contrary to what you write above, this is /not/ the formantics of and-then in Ada. In Ada, the conditional boolean operators are not symmetric: "A and-then B" is not equivalent to "A and-then B". So you are proposing something new in the language beyond the mere choice of lexemes. The formantics you propose would be an exception handler that does not discriminate neither for the type of the exception, nor for the side of the operator where it was raised. The ambiguity of both sides raising an exception is handled by rule 2 below. The formantics you propose would execute the else-branch for *any* exception, not just the divide by zero in the example, but also overflows and Gods knows what else. A nice place for bugs to hide. It is even worse than that: if there is no else-branch, then the execution silently continues after the end-if. Great. Bugs now go completely undetected. The worst possible thing you could do for high-integrity software. > 2. If both raise A and B an exception, of if one raises an exception and > the other one is true, an exception is propagated. Why not follow your own logic and really use a three-valued logic and introduce a three-branched if-then-else structure with a third branch for handling "undefined and undefined" or whatever you call it. > 3. I would be willing to pragmatically sacrifice mathematical purity for a > shortcut rule: If A is false, the expression is false, whatever B does. > If A raises an exception, of if A is true and B raises an exception, > the exception is propagated. Congratulations, you just reinvented the and-then in Ada. > 1. and 2. describe some "ideal" behaviour, but 3. describes what the one > can realistically expect from the compiler. BTW, the compiler would not > need to be that incredibly smart. If an exception is raised when > evaluating a Boolean expression, the exception could be handled inernally, > to finish evaluating the Boolean expression, and re-raised if neccessary. 1+2 may appear ideal for a mathematician, because of the symmetry it provides. But we are not doing mathematics. I am a professional software engineer and I do not want my stupid mistakes, that I do make, caught by contracts that raise all sorts of violations (program exceptions), go unnoticed because the exception is silently handled in the else-branche or not at all if there is no such branche. Ideal behavior is a fata morgana from lala-land. We have to deal with fallible developers and machinery. > ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ > Stefan dot Lucks at uni minus weimar dot de > ------ I love the taste of Cryptanalysis in the morning! ------