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.3 required=5.0 tests=BAYES_00,INVALID_MSGID,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9e90e30a519a635b
X-Google-Attributes: gid103376,public
From: r_c_chapman@my-deja.com
Subject: Re: return statements in procedures
Date: 2000/06/05
Message-ID: <8hfujg$nl5$1@nnrp1.deja.com>#1/1
X-Deja-AN: 631211299
References: <393B2054.618F6E80@baesystems.com.au>
X-Http-Proxy: 1.0 PROXY,
 1.0 x57.deja.com:80 (Squid/1.1.22) for client 193.114.91.187
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Mon Jun 05 10:15:20 2000 GMT
X-MyDeja-Info: XMYDJUIDr_c_chapman
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.73 [en] (WinNT; U)
Date: 2000-06-05T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <393B2054.618F6E80@baesystems.com.au>,
  Matthew Daniel <matthew.daniel@baesystems.com.au> wrote:
> Hi,
>
> we are having a "discussion" at work at the moment about return
> statements in procedures.

For what's it worth, they're not allowed in SPARK, and I don't
really miss them.  I can only think of one or two occasions in the
last 5 years when I've really needed such a thing.  The restricitons
on return statements in SPARK are such that subprograms always
have a single-entry/single-exit flow graph, which makes
subsequent Flow Analysis and Verificaiton Condition Generation
much easier..
 - Rod Chapman
   SPARK Team, Praxis Critical Systems, rod@praxis-cs.co.uk



Sent via Deja.com http://www.deja.com/
Before you buy.