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
X-Google-Thread: a07f3367d7,5add429c86f59001
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!de-l.enfer-du-nord.net!usenet-fr.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Ada vs Eiffel - Ada programmer approach
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: 
 <405b5054-4c8f-4e16-9ea8-503a9b9f976e@t21g2000yqi.googlegroups.com>
  <4A19765C.608@obry.net>
 <8105b65f-4de9-4653-b43a-d55ee33f072d@k2g2000yql.googlegroups.com>
 <130yh6dv3l1lf$.1729u4tpolgwi.dlg@40tude.net>
 <4a1c2652$0$30220$9b4e6d93@newsspool1.arcor-online.net>
Date: Tue, 26 May 2009 19:39:39 +0200
Message-ID: <1r1ho3wqsjncb.1p3p7qe2qcqmw.dlg@40tude.net>
NNTP-Posting-Date: 26 May 2009 19:39:39 CEST
NNTP-Posting-Host: 37464adc.newsspool4.arcor-online.net
X-Trace: 
 DXC==lLl\k_jT:n<6cDJZfMd_c4IUK<Cl32<a4Fo<]lROoRa^YC2XCjHcbiE2JJE?:l4XiDNcfSJ;bb[eIRnRBaCd<MnT6NQQB3U^Rfl]9_NW1^2gk
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:6023
Date: 2009-05-26T19:39:39+02:00
List-Id: <comp.lang.ada>

On Tue, 26 May 2009 19:26:42 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Tue, 26 May 2009 06:37:49 -0700 (PDT), Ludovic Brenta wrote:
> 
>>> - pre/post conditions and invariants involve run-time checks most of
>>> the time (if not all the time). They slow the program down if enabled,
>>> or become useless when disabled for performance.
>> 
>> There should be no run-time contract checks. That is inconsistent:
>> 
>> function Return_False return Boolean is
>>     -- The contract of Return_False is to return False
>> begin
>>    if Is_OK (Return_False) then
>>       -- Is_OK returns True if Return_False satisfies its contract
>>       return True;
>>    else
>>       return False;
>>    end if;
>> end Return_False;
>> 
>> Now, if Return_False is OK, then Is_OK returns True and then Return_False
>> returns True and so it is not OK. So is it, or is it not?
> 
> Eiffel defines the conditions for when a contract's assertions
> will be tested. In particular, not every call will
> trigger the tests. ;-)

Certainly. They are tested when do not assert contracts. (:-))

>  So the never ending loop above is
> not a problem within the Eiffel DbC framework of definitions.
> (The stack may overflow, though.)

There is no loop since "contract is satisfied" is not a variable. Otherwise
you cannot design "by contract", obviously. Even considering some
test-driven-design rubbish, since the target is oscillating, your design
will never end. You cannot work around an inconsistency.

Whatever you check or assert at run-time that is not a contract. The effect
of checking is a behavior. Contract check cannot be a behavior. That is the
inconsistency of Eiffel's approach, as well as one of Ada's pragmas if they
have any run-time effects.

Ada's static typing system and SPARK do it right.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de