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: 
 border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.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: Tue, 23 Dec 2014 11:41:36 +0100
Organization: A noiseless patient Spider
Message-ID: <m7bgsa$f5t$1@dont-email.me>
References: <2430252d-52a1-4609-acef-684864e6ca0c@googlegroups.com>
 <c17f6550-1cc8-4ef7-8477-4512d16d294a@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: Tue, 23 Dec 2014 10:41:14 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="087f226d377da1e1558f227c18fbfe5a";
 logging-data="15549"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1+R/aX9GIX4f+lljkQugOQXIQRwK14zwS0="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <c17f6550-1cc8-4ef7-8477-4512d16d294a@googlegroups.com>
Cancel-Lock: sha1:PTHN9BxFEDeSFOERmhpTxOqjeqY=
Xref: number.nntp.giganews.com comp.lang.ada:191510
Date: 2014-12-23T11:41:36+01:00
List-Id: <comp.lang.ada>

On 22.12.14 20:38, sbelmont700@gmail.com wrote:
> Now you've got a function that doesn't access any global variables, but not only randomly exhaust the heap, but also permanently blocks the thread, so you are right back where you started.

A function call can "cause" even more, pure or not. Any Ada
check can have effects.

Add to Randy Brukardt's response that everything manipulates
"the program"'s state. Invoking any function can also exhaust
resources, e.g. hit the stack limit. But that's then the catch
all Standard.$Runtime$_Error.

However, there are two notions to keep in mind, I think:

1. Contract based design, or at least Design by Contract™, entails
a proof obligation(*).  Without it, the former is sill a very useful
debugging tool, or testing tool.

2. The model of contract based design should not be confused with
its implementation, I think: For example, the checks may be performed
on a multiprocessor computer in such a way that one of the processors
checks a copy of a sequential program, while the other does not check.

There might be theoretical corner cases where duplication is not
possible. It might be impractical to detect important differences
in the copies' states, but you get the idea, in particular with (1)
in mind: proof obligations.

In fact, a duplicated setup does not seem to be entirely dissimilar
from redundant installations already in use?

__
(*) At Ada Europe 2012, Betrand Mayer explains that Eiffel programs
in production are supposed to run with checks disabled.