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.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	FREEMAIL_REPLYTO,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Thread: a07f3367d7,5bcfd29df81c93e0
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.66.232.162 with SMTP id tp2mr5379212pac.29.1367665588564;
        Sat, 04 May 2013 04:06:28 -0700 (PDT)
Path: 
 ln4ni1321pbb.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!News.Dal.Ca!news.litech.org!news2.arglkargh.de!newsfeed.fsmpi.rwth-aachen.de!newsfeed.kamp.net!newsfeed.kamp.net!news.qsc.de!zen.net.uk!hamilton.zen.co.uk!reader03.nrc01.news.zen.net.uk.POSTED!not-for-mail
From: Phil Thornley <phil.jpthornley@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: SPARK Question
Date: Wed, 1 May 2013 14:35:20 +0100
Message-ID: <MPG.2beb2a4dab7f2a819896a7@news.zen.co.uk>
References: <0efb385b-279a-49b7-8289-86b0e99e7930@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: f5e3fb49.news.zen.co.uk
X-Trace: 
 DXC=cW\_R[m3VX8Z][238HZlA>f2FgniPJjg2=dR0\ckLKG0WeZ<[7LZNR6^LO=^d7eHK9UhLi?]0KG=;4[kLFU:ROU?kML7B7EO:h:
X-Complaints-To: abuse@zen.co.uk
X-Received-Bytes: 3887
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 2013-05-01T14:35:20+01:00
List-Id: <comp.lang.ada>

In article <0efb385b-279a-49b7-8289-86b0e99e7930@googlegroups.com>, 
enzmann.m@googlemail.com says...

[snip]

> The vector can now hold a maximum of "Number_Of_Elements" Values, 
although the actually used length will in most cases be smaller. This 
"true" length is shown by the component "Length" in the record.
> 
> Reading a single element of the vector now needs a function
> 
> >   function Get_Value
> >     (The_Vector : in Basic_Vector;
> >      At_Position : in Positive)
> >      return Basis_Type;
> >   --# PRE At_Position in Array_Range;
> 
> which clearly will not work if "At_Position" is larger than "Number_Of_Elements". Furthermore it will however not give a useful result, if "At_Position" is larger than "The_Vector.Length".
> 
> How can I express this in a pre-condition? I can write a function
> 
> >   function Vector_Length (The_Vector : in Basic_Vector) return Positive;
> 
> and use this in the pre-condition. This leaves however a couple of questions open, so I'd prefer to do this in a different way.
> 
> As far as I understand, a proof-function 
> 
> >   --# function Vec_Length (The_Vector : in Basic_Vector) return Positive;
> 
> 
> could do the trick in the specification and a more elaborate version of the
> pre-condition will then be used in the body. I have however no idea, how the
> two are linked and how I can express the relationship in the rules file.

Assuming you are using the latest version of SPARK, the simplest way to 
do this is to also include the proof function Vec_Length in the body, 
and give it a return annotation. So in the spec put:

   --# function Vec_Length (The_Vector : in Basic_Vector)
   --#   return Positive;

   function Get_Value
     (The_Vector : in Basic_Vector;
      At_Position : in Positive)
      return Basis_Type;
   --# PRE At_Position in Array_Range'First .. Vec_Length(The_Vector);

and in the body put:

   --# function Vec_Length (The_Vector : in Basic_Vector)
   --#   return Positive;
   --# return The_Vector.Length;

With the other code as you have it in your post, this leaves one 
unprovable VC for Get_Value, as the value of Length in the record is 
declared as Natural.  If  this is changed to Array_Range it makes the VC 
provable, and proved by the Simplifier. (But this then means that you 
cannot have an empty vector - which can be fixed by declaring another 
subtype for Length that includes 0).

You need to be aware that by doing it this way rather than having a 
coded function for Vec_Length (which you say you don't want to do) you 
are making a claim for Vec_Length that cannot be validated by the proof 
tools.  (See section 3.3 of the document "Calling functions in SPARK 
proof contexts").

Cheers,

Phil