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: 
 border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!ottix-news.ottix.net!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: {Pre,Post}conditions and side effects
Date: Tue, 23 Dec 2014 16:35:34 -0500
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wccioh2oxqx.fsf@shell01.TheWorld.com>
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>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: pcls7.std.com 1419370536 4510 192.74.137.71 (23 Dec 2014 21:35:36
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Tue, 23 Dec 2014 21:35:36 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:3qzK8BlRC7wUlv+8ap24gTZNyL4=
Xref: number.nntp.giganews.com comp.lang.ada:191514
Date: 2014-12-23T16:35:34-05:00
List-Id: <comp.lang.ada>

Jean François Martinez <darkquark99@gmail.com> writes:

> On Tuesday, December 23, 2014 6:05:33 PM UTC+1, Robert A Duff wrote:
>
>> I don't agree with that.  It sometimes makes sense for pre/post to
>> check values of global variables.  Probably not often -- after all,
>> it's not often that you should have global variables in the first place.
>> But surely if the job of a procedure is to update some global,
>> it makes sense to have a postcondition ensuring that it did so
>> correctly.
>
> That was clumsy (I was in a hurry) wording of my part.  Should have
> been "a pre/postconsition/invariant" usually don't involve redoing the
> whole calculation but just checking values of "data entities" both in
> the absolute and relativly to one another.  Most of the tilme you
> don't write pre/postonditions/invariants involving (with functions
> cvalled) tens of thousands of programming lines and gazillions of CPU
> cycles

Yes, I agree.  The best assertions are much shorter than the executable
code.  For example:

    function F return Integer is (123) with Post => F'Result = 123;

If you manage to prove that postcondition, you haven't accomplished
much.  Likewise, if 123 were replaced (in both places) with 1000 lines
of code, you still haven't accomplished much -- it's just as likely
there's a bug in the postcondition as in the function itself, especially
if the postcondition duplicates the function, which I assume is what you
meant by "redoing the whole calculation" above.

But if the function is long, but its postcondition is short, then
proving the postcondition is a big win.  The goal is to somehow
characterize what the function is supposed to do more concisely than the
code that does it.  Not always easy.

- Bob