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!news2.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps82.POSTED!53ab2750!not-for-mail Sender: blaak@METROID Newsgroups: comp.lang.ada Subject: Re: and then... (a curiosity) References: <18b41828-bda4-4484-8884-ad62ce1c831d@f36g2000hsa.googlegroups.com> <57qdnfULQ9tzKCHVnZ2dnUVZ_tHinZ2d@comcast.com> <48bd0003$1@news.post.ch> <12prmxev8newf.lvc4m055okkb$.dlg@40tude.net> <1vmbk6d18az86$.hfgj8yjrvho8$.dlg@40tude.net> From: Ray Blaak Message-ID: Organization: The Transcend User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Sep 2008 06:34:16 GMT NNTP-Posting-Host: 154.20.96.87 X-Trace: edtnps82 1220596456 154.20.96.87 (Fri, 05 Sep 2008 00:34:16 MDT) NNTP-Posting-Date: Fri, 05 Sep 2008 00:34:16 MDT Xref: g2news2.google.com comp.lang.ada:7664 Date: 2008-09-05T06:34:16+00:00 List-Id: stefan-lucks@see-the.signature writes: > > This is not funny. This one kills the idea, unless you forcefully convert > > all exceptions into Constraint_Error, when a non-Boolean value is converted > > to Boolean. > > If I would actually propose something like that, I would probably propose > to raise Program_Error if the exceptions aren't all the same. If you have a situation where all operands are evaluated, then the exceptions raised should only be those from the operand expressions themselves under normal language rules: Constraint_Error if appropriate, whatever explicit exception a function raises, etc. To do anything else gives way to madness. If nothing else, it would be quite difficult to determine the root cause of an exception, and examining source code would not give obvious reasons. The only way out is to have partial evaluation of boolean expressions, so that you can have guard operands *and* consistent exception rules. But Ada already has that with "and then" and "or else", so consistently use that if you wish. The reasons of having "and" and "or" evaluate both operands is a least consistent and logical according to Ada rules, especially given that they are semantically function calls. It's just that for me, if I see a boolean expression, I am by instinct evaluating the boolean logic, not seeing the side effect of evaluating all operands. If that needs to be stressed, i.e., is an explicit requirement, I prefer the code to more clearly spell out that required evaluation, and leave the boolean combination of the results as a separate step. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.