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,ad06d2d7cb045687
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.238.198 with SMTP id vm6mr2109392pbc.3.1328188857832;
        Thu, 02 Feb 2012 05:20:57 -0800 (PST)
Path: 
 lh20ni252238pbb.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!xlned.com!feeder1.xlned.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 02 Feb 2012 14:20:55 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Silly and stupid post-condition or not ?
References: <op.v8w6ptk5ule2fv@douda-yannick>
 	<82wr86fzos.fsf@stephe-leake.org>
 	<5af407fc-2868-44ca-84d2-c51a2a64104d@o4g2000pbc.googlegroups.com>
 <82k445fu9n.fsf@stephe-leake.org>
In-Reply-To: <82k445fu9n.fsf@stephe-leake.org>
Message-ID: <4f2a8db8$0$7613$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 02 Feb 2012 14:20:56 CET
NNTP-Posting-Host: 539fc54b.newsspool1.arcor-online.net
X-Trace: 
 DXC=Y;kCocGfMI0;]cDoEWD6A4ic==]BZ:af>4Fo<]lROoR1<`=YMgDjhg2VlijeZK>]H1nc\616M64>:Lh>_cHTX3j=NIfb@27O]N:
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: 2012-02-02T14:20:56+01:00
List-Id: <comp.lang.ada>

On 02.02.12 10:40, Stephen Leake wrote:

> post conditions should be _complete_. If the Ada
> post condition language is not strong enough to be complete, don't use
> it; use natural language comments.

First, there is no completeness in most real program systems
product; it seems honest, then, to not assume we could manage
to even potentially achieve it is Post aspects, IMHO.
Yet, program system products use formal language.  The use
of formal language means best effort, not completeness of
all kinds, I think.

Post aspects can help being productive:

If programmers know something about the possible outcomes
of a subprogram, they can act accordingly. If there is a
specification that says: the result is such that if P1(Result)
then also P2(Result), they can act accordingly.

A postcondition gives programmers something to work with.
Since natural language does not change the correspondence of
postcondition and programmers writing based on assumptions
about the postcondition, formal language addressing some
results still produce an informed state of mind, a better
one, I think.

As another example,

   type Match (Found: Boolean) is record
      case Found is
          when True =>
             Value : Big_Natural;
          when False =>
             null;
      end case;
   end record;

   procedure Goldbach (A, B: Big_Natural; Result: Match)
     with Post =>
     (if A + B < Highest_Known_Sum then
       (if Result.Found then
               Is_Prime (A)
           and Is_Prime (B)
           and Result.Value mod 2 = 0)
     else  -- larger
       (if Result.Found then
	 Result.Value mod 2 = 0));

Post says that whenever there is a result and it is larger
than some state-of-the-art value, go look and see whether
A and B are prime. If not Result.Found, then data would be thrown
away in any case. Thus, precisely because there is some
kind of formal incompleteness here, the Post aspect tells
something about the results that will not get thrown away.