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.7 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM,FREEMAIL_REPLYTO,REPLYTO_WITHOUT_TO_CC autolearn=no
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,78ad7a7a1db15587
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.220.230 with SMTP id pz6mr25615148pbc.3.1340268448188;
        Thu, 21 Jun 2012 01:47:28 -0700 (PDT)
Path: 
 l9ni2603pbj.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!zen.net.uk!dedekind.zen.co.uk!reader02.nrc01.news.zen.net.uk.POSTED!not-for-mail
From: Phil Thornley <phil.jpthornley@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Need help understanding SPARK substitution rules
Date: Thu, 21 Jun 2012 09:47:20 +0100
Message-ID: <MPG.2a4cefcee608275a98969a@news.zen.co.uk>
References: <84581b9d-040b-493b-a8af-ab3499001b5d@googlegroups.com>
Reply-To: phil.jpthornley@gmail.com
MIME-Version: 1.0
User-Agent: MicroPlanet-Gravity/3.0.4
Organization: Zen Internet
NNTP-Posting-Host: ca0ff5b2.news.zen.co.uk
X-Trace: 
 DXC=@IiT]0c:0KminCmPbdZEoc]G;bfYi23hd=dR0\ckLKG`WeZ<[7LZNRfiBC[PJ9Mgmg6JNOYoB;SJn9[[@oYI29]oFZIZBQTDcZc
X-Complaints-To: abuse@zen.co.uk
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 2012-06-21T09:47:20+01:00
List-Id: <comp.lang.ada>

In article <84581b9d-040b-493b-a8af-ab3499001b5d@googlegroups.com>, 
benjaminhocking@gmail.com says...
> 
> I have the following math.ads:
[code snipped]
> The statement "check not (InVal > 0) -> InVal <= 0" is proven easily
> enough, but the next line ("check not IsPositive(InVal) -> InVal <=
> 0") is not, even though it's functionally equivalent. If I put the
> following line in math.rlu:
> ========
> math_ispositive: ispositive(inval) may_be_replaced_by (inval > 0)
> ========
> It now can prove it, and if I do the same thing with isnegative, the
> whole thing proves out (with the "return True" component being proven
> by ViCToR).
> 

What you need is for the Examiner to include the return expressions in 
the hypotheses - it does (now) do this, but only for VCs generated for 
code that follows the function call. (See Proof Manual Section 8.4.9 - 
bullet point 4)

So if you change your code to

   function AlwaysTrue (InVal : in Integer) return Boolean is
      Result : Boolean;
   begin
      Result := (not IsPositive(InVal) or not IsNegative(InVal));
      --# check not (InVal > 0) -> InVal <= 0;
      --# check not IsPositive(InVal) -> InVal <= 0;
      --# check not (InVal < 0) -> InVal >= 0;
      --# check not IsNegative(InVal) -> InVal >= 0;
      return Result;
   end AlwaysTrue;

then the VCs generated for the check annotations include hypotheses such 
as:
H7:    ispositive(inval) <-> (inval > 0) .

Now the only VC left unproven by the Simplifier is the last one (which 
you note is proved by Victor).

For those of us who (so far) find Victor (I loathe that casing they've 
adopted) not practicable for anything other than trivial code snippets, 
the one remaining VC can be proved by the rule:

boolean(1): not A or not B
              may_be_deduced_from
          [ A <-> X > 0,
            B <-> X < 0 ] .

which has the merit of being universally true and avoiding any "code 
smell".

Furthermore this rule can then be validated by proving the corresponding 
VC:

H1:  a <-> x > 0 .
H2:  b <-> x < 0 .
   ->
C1:  not a or not b .

(There are hints that this approach to validating rules will be 
described in the next version of the SPARK book).

Cheers,

Phil