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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Tests in a software release Date: Thu, 16 Nov 2017 18:15:52 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Fri, 17 Nov 2017 00:15:52 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="24856"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: feeder.eternal-september.org comp.lang.ada:48942 Date: 2017-11-16T18:15:52-06:00 List-Id: "G.B." wrote in message news:oul0ra$jee$1@dont-email.me... > On 15.11.17 23:17, Randy Brukardt wrote: > >> ... >>> The most important thing is, designing by contract >>> is *not* programming defensively. By definition. >> >> One *always* programs defensively. > > Why would that be? Because the real world is a nasty place where unexpected things go wrong. The fewer assumptions a human has to make, the the better. A computer program can handle making assumptions much better, because it can juggle many of them and will not get confused. > FTR, and for what the definitions are, > http://se.ethz.ch/~meyer/publications/computer/contract.pdf > > Referring to some notes from your blog, you cannot always > > - compute things at compile time, hoping to optimize; > - perform run-time checks in a timely fashion, without > checks causing timeouts: My blog was exclusively talking about language-defined constructs and checks. None of the rules described in the blog have any effect on user-defined operators (that is, ordinary function calls) because the compiler cannot know what the body does. Indeed, my entire discussion here has been about pragma Suppress and does not necessarily apply to user-defined contracts (that is, pragma Assertion_Policy as applies to things like Pre and Post). There is absolutely no connection between pragma Suppress and pragma Assertion_Policy in Ada -- they work entirely differently (Assertion_Policy(Ignore) cannot by itself cause erroneous execution, while pragma Suppress almost always can). A lot can be done with user-defined contracts, but that depends on contract aspects not defined in Ada 2012 (like Global, which hopefully will be in Ada 2020). As you note correctly, timing issues might still require using Ignore, since it is easy to write very expensive predicates that cannot be left in a production system. I believe that latter problem is a flaw in the contract system as written; most predicates are *not* expensive (think Is_Open in Text_IO) and thus have no need to be Ignored; it would be best if the occassional expensive predicate could be flagged and only those ignored. But again, none of that has anything to do with what I was discussing. ... > On the contrary: you write the contract's clauses of > all parties to your compiler and then, once you > know your code meets the requirements of the contracts, > you drop checking code accordingly ("optimize") and in > good conscience. Never for language-defined checks; there is no point as any barely competent compiler will drop them automatically for free. If it can't drop them, it's highly likely that your code has a bug. User-defined contracts are a different deal; I'd prefer to never eliminate them, either, but I recognize that a few are going to be too expensive, and it's not as clear that the compiler will be able to optimize them (although in many cases, it will be able to do so to get sufficient performance). ... > if X /= X or else X /= X then > > -- what, at compile time, > -- for which which kind of X? This is dubious for *ANY* kind of X. This is just a warning because X might be something with a side-effect and thus this might actually mean something other than the nothing that it appears to mean -- but even in such a case, the code is clearly tricky and it would be better written some other way that is less tricky to a reader that doesn't necessarily know the details of X. This is all explained in detail in the blog and I'm not sure why you are asking about it here. Randy.