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=ham
	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!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 26 May 2009 19:26:42 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ada vs Eiffel - Ada programmer approach
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>
In-Reply-To: <130yh6dv3l1lf$.1729u4tpolgwi.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4a1c2652$0$30220$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 26 May 2009 19:26:42 CEST
NNTP-Posting-Host: 19bc4a96.newsspool1.arcor-online.net
X-Trace: 
 DXC=Vh^ZGPVNiYZ5TOT9_N5i<Vic==]BZ:af^4Fo<]lROoRQ^YC2XCjHcbYVNJKER]6RaS;9OJDO8_SKVNSZ1n^B98iZVa_T<7=[AK]
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:6022
Date: 2009-05-26T19:26:42+02:00
List-Id: <comp.lang.ada>

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. ;-)  So the never ending loop above is
not a problem within the Eiffel DbC framework of definitions.
(The stack may overflow, though.)