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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada 2012 Constraints (WRT an Ada IR) Date: Tue, 6 Dec 2016 11:01:19 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <03847fd7-5699-48de-bb3c-ef5512398f26@googlegroups.com> <3ef819e8-55f7-4ef7-9f37-77e6abc33f98@googlegroups.com> <47366b42-c0a3-41bf-a44a-5241c109d60f@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:32638 Date: 2016-12-06T11:01:19+01:00 List-Id: On 06/12/2016 10:29, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On 2016-12-05 23:12, Randy Brukardt wrote: >>> "Dmitry A. Kazakov" wrote in message >>> news:o23a8a$11e9$1@gioia.aioe.org... >>> ... >>>> Things called in Ada pre- and post-conditions if evaluated during >>>> run-time are merely subprogram bodies booby-trapped with >>>> unanticipated exceptions. Bad thing. >>> >>> Until you compare to the alternative, which is a subprogram body that >>> gives the wrong answer without detection. As I said in another >>> message, a visible bug is much better than an invisible bug. >> >> The alternative is a contract to raise exception. So there is no bug >> anymore, just well-defined behavior. > > I'm sorry, but this argument is ridiculous. If I write the code to > implement the required behaviour to the best of my ability, but get it > wrong, then the code will not have the required behaviour and will not > meet any contract that might be placed on it. It is called a bug. E.g. you implement addition and 2+2 yields 5. > The equivalent of your contract would be > > with Post => Correct_Behaviour_Implemented > or else Something_Terrible_Occurs; > > which isn't worth saying. 1. It is not my contract. My contract would be "in the range" or else exception. Which means the caller must be prepared to handle the exception. Your alternative is that the contract is "no exception" but the caller gets it anyway. That is clearly a violation. Either of the parties must be fixed before compiling. Now, if you cannot fix the callee to ensure the thing in the range, be honest to the caller => make exception into the contract. 2. You cannot specify all behavior through the contracts. Contracts are necessarily weaker than that. You can roughly outline some of the behavior in the contract, like: in the range vs. out of the range. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de