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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,b78c363353551702
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.238.65 with SMTP id vi1mr6841651pbc.7.1340448453218;
        Sat, 23 Jun 2012 03:47:33 -0700 (PDT)
Path: 
 l9ni10334pbj.0!nntp.google.com!news1.google.com!goblin3!goblin.stu.neva.ru!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!usenet-fr.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sat, 23 Jun 2012 12:46:56 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: about the new Ada 2012 pre/post conditions
References: <jrsjr7$uuo$1@speranza.aioe.org>
 <1hgo6aks03zy.by4pq4xbjsgf$.dlg@40tude.net> <jrsmfh$6fq$1@speranza.aioe.org>
 <npdjip6ohqlt$.1x6bxc9jsaago$.dlg@40tude.net> <js00co$clj$1@munin.nbi.dk>
 <1jvy3elqtnd1j.1sjbk32evhp1f$.dlg@40tude.net> <js2hq5$9fj$1@munin.nbi.dk>
 <1oih2rok18dmt.avbwrres5k12.dlg@40tude.net>
In-Reply-To: <1oih2rok18dmt.avbwrres5k12.dlg@40tude.net>
Message-ID: <4fe59ea0$0$9502$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 23 Jun 2012 12:46:56 CEST
NNTP-Posting-Host: 3c5526fe.newsspool1.arcor-online.net
X-Trace: 
 DXC=8_3ZJilQ13;Tia]Ho99G50ic==]BZ:af>4Fo<]lROoR1nkgeX?EC@@0C[<4Pd9AVH2PCY\c7>ejV81<c1Tb^_gV?``e@aO4gAE3
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-06-23T12:46:56+02:00
List-Id: <comp.lang.ada>

On 23.06.12 01:08, Dmitry A. Kazakov wrote:
>> And Ada*always*  has had dynamic preconditions:
>> >
>> >       procedure New_Line (Spacing : in Positive_Count := 1);
> The precondition here is Spacing in Positive_Count'Base because the
> behavior of New_Line is*defined*  when Spacing is not in
> Positive_Count'Range.
>
>     New_Line(0)
>
> is a*legal*  Ada program.
  
The behavior of New_Line is not relevant, because New_Line's body
is not performed when "Spacing not in Positive_Count". New_Line does not
behave, because it can't; it also does not propagate anything from its
body. The program does behave without New_Line being called.
But that's the point.

Although there is a post-state in the program, the subprogram New_Line
does not get a chance to run, hence cannot establish its (its!)
postcondition.  Its postcondition is conceptually different
from the condition the program is in, at the place after the New_Line
statement.

When New_Line (Spacing) where

  Spacing in Positive_Count'Base

is legal Ada, then still New_Line (Spacing) where

  Spacing not in Positive_Count

is a contract violation, duly noted by an Ada program executing
properly.

The notions of precondition seem to differ.

Looking at assignments of variables before a call and then calling
this set the precondition, and then looking at assignments and exceptions
after the call, if any, and calling that set the postcondition,
is too meaningless and narrow to be equated to DbC.

There are two separate kinds of rules working here.