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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: {Pre,Post}conditions and side effects
Date: Sat, 25 Apr 2015 18:37:13 +0200
Organization: A noiseless patient Spider
Message-ID: <mhgfps$a0j$1@dont-email.me>
References: <2430252d-52a1-4609-acef-684864e6ca0c@googlegroups.com>
 <AnYlw.957256$Rp.242412@fx23.iad>
 <0a718b39-ebd3-4ab5-912e-f1229679dacc@googlegroups.com>
 <wccoaqucn51.fsf@shell01.TheWorld.com>
 <9ee5e186-5aaa-4d07-9490-0f9fdbb5ca18@googlegroups.com>
 <alpine.CYG.2.11.1412231747100.4196@WIL414CHAPIN.vtc.vsc.edu>
 <wccegrpq2om.fsf@shell01.TheWorld.com>
 <87tww5296f.fsf@adaheads.sparre-andersen.dk> <871tj9dp5b.fsf@theworld.com>
 <ce4af31e-d491-479f-a5b3-0b3eedea2a68@googlegroups.com>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 25 Apr 2015 16:36:12 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="ca7205cc7eda2397a4f2215cd25aac5e";
	logging-data="10259"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19td9+WAj2HsjyHIJoxGYebXE5M18AYpJY="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
In-Reply-To: <ce4af31e-d491-479f-a5b3-0b3eedea2a68@googlegroups.com>
Cancel-Lock: sha1:m75ucnKD6V1hDDbqvGf/Zy4t3e4=
Xref: news.eternal-september.org comp.lang.ada:25626
Date: 2015-04-25T18:37:13+02:00
List-Id: <comp.lang.ada>

On 25.04.15 14:08, vincent.diemunsch@gmail.com wrote:
> But what Ada and SPARK 2014 are doing is "design by contract", as Bertrand Meyer
> called it. This makes a confusion between a precondition and a runtime test.

Actually, Meyer insists that contracts have an associated
notion, that of proof obligation. And the description of DbC
is declaring quite openly that not needing to perform run-time
tests (e.g. defensive programming) is a design goal.

What you get in the lesser (than some fancy ideal) situation is
summarized in a table of OOSC2, §11.6 (coincidence? ;-), for a stack:

   Put        OBLIGATIONS          BENEFITS

Client    satisfy Pre=>...        from Post=>...

          Only call Put(X) on     Get stack updated: not
          a non-full stack.       Empty, X on top, Item yields
                                  X, Count increased by 1.

Supplier  satisfy Post=>...        from Pre=>...

          Update stack reprsntn   Simpler processing thanks
          to have X on top (Item  to the assumption that
          yields X), Count        stack is not full.
          increased by 1, not
          Empty.


Looking at SPARK 2014, it seems to not have changed earlier SPARK
WRT being a tool for analysis before run-time.

Ada, OTOH, looks like becoming a programming language facilitating
either type of checking, as before, but more extensively and more
formally, and more of it to write for the programmer.