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: function Is_Open (File : File_Type) return Boolean; :Text_io
Date: Fri, 30 Oct 2015 02:06:43 +0100
Organization: A noiseless patient Spider
Message-ID: <n0ufn3$e6$1@dont-email.me>
References: <f30bbb5d-ebfd-427b-8c16-88aeb8a61318@googlegroups.com>
 <87twpd2qlo.fsf@theworld.com> <1pj15r7pul7f1.15qgdyrc8k133$.dlg@40tude.net>
 <87pp0030c1.fsf@theworld.com> <135hiczk56x02.1xixcme8btbl4.dlg@40tude.net>
 <n0o9fb$3pq$2@dont-email.me> <1dzlgoh4u2j7t$.1un3dfy0oeigd$.dlg@40tude.net>
 <n0qa3q$th8$1@dont-email.me> <190shqocxd87d$.1d68ghgqgbvfs$.dlg@40tude.net>
 <n0t0t1$56e$1@dont-email.me> <19ihs115mzocg$.20s63jo0q2gf.dlg@40tude.net>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Oct 2015 01:04:35 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="dcdfba98b41ca3ea93d95f4f82c9b50e";
	logging-data="454"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+hIcO6oK53fwB/kQXW63ZZb90BQYwZtQQ="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <19ihs115mzocg$.20s63jo0q2gf.dlg@40tude.net>
Cancel-Lock: sha1:IjaUlVvEIXZgUYfUBRCWVPKgU/8=
Xref: news.eternal-september.org comp.lang.ada:28119
Date: 2015-10-30T02:06:43+01:00
List-Id: <comp.lang.ada>

On 29.10.15 15:00, Dmitry A. Kazakov wrote:

> Contracts may have no effect on program execution.

(Must have no effect?)

Did I miss why? I saw picking a universe that suffers from failure
to respond usefully to some runs of programs failing, even in some
expected way. There was also the assumption of the existence of a
single allowed run-time effect for each pair <source program, input>.

Naturally, contracts will have no effect at run-time when tools and
brains are capable of demonstrating that all assertions will always
be true. For me, this is just a dream.

>  Consider this:
>
> program describes execution
> contract describes program(s)
> documentation describes anything

Yes, the definitions look like the rattling machinery of clean room
program analysis and fully informed decision making.

HOMER: (stands up) "Boring!"

I think the third line (documentation describing *anything*) is troublesome,
in part because the generality might lead to a paradox, and because it
remains unclear to me if documentation describes program(s) or execution.
Also how, if not using either the contract or the program.

>> Even so, I think that an implementation of Ada could "outsource"
>> assertion checking to some read-only copy of the program that
>> is running on a twin processor, suitably connected, so as to
>> reduce run-time effects of assertion checking.
>
> We discussed that earlier. You can have program A asserting program B. You
> never can do this in a single program. That is inconsistent.

There is no program A, as A is a template. Instances (for runs) are
created when choosing an Assertion_Policy, or levels of optimization,
say. If levels of optimization may change formal semantics (11.6 IIUC),
then why is optimization o.K., but controlling assertion checking is not?
Just because of some thin, formal, logical concern that contracts pushing
us into the morass of recursion is as problematical as most programming?

Anyway, if a Rational R-1000 did perform checks on a coprocessor,
perhaps we just need another word? So that we could say
"formal description of program(s)" when we mean it and use "contract"
instead for what seems to be its "other" meaning?