comp.lang.ada
 help / color / mirror / Atom feed
From: Peter Amey <pna@praxis-cs.co.uk>
Subject: Re: exiting a bloc
Date: Wed, 13 Sep 2000 11:02:55 GMT
Date: 2000-09-13T11:02:55+00:00	[thread overview]
Message-ID: <8pnmsn$7cn$1@nnrp1.deja.com> (raw)
In-Reply-To: 39BF3C11.CA3A9347@amsjv.com

In article <39BF3C11.CA3A9347@amsjv.com>,
  Philip Anderson <phil.anderson@amsjv.com> wrote:
> Robert Dewar wrote:
> >
> > In article <8pl3qa$ivi$1@trog.dera.gov.uk>,
> >   icaldwell@dera.gov.uk (Ian Caldwell) wrote:
> > > When I used "the SPARK subset of Ada" I meant SPARK without
> > any of its
> > > annotations. I know that not the full SPARK language.  Maybe I
> > should have used
> > > the Ada subset of SPARK (meaning the part of SPARK that is
> > Ada).
> >
> > It would be convenient (and perhaps avoid confusion) to have
> > a clear name for that subset :-)
>
> Praxis refer to the overlap between SPARK and Ada as "the common
> kernel"; the SPARK core is then this common kernel + the core
> annotations (there are also optional proof annotations).  The SPARK
Ada
> kernel is probably the least ambiguous term.
>
> For those who don't know, the SPARK annotations take the form of Ada
> comments with a defined syntax, all beginning --# (or --$ in our
case),
> and so a SPARK program is legal Ada and can be compiled by any Ada
> compiler; the SPARK Examiner is an additional tool which does not
> compile but verifies the SPARK code (the Ada kernel + annotations).
In
> addition, something like Rational's Apex Ada Analyser can be set up to
> analyse an Ada program and flag non-SPARK Ada, but that does nothing
> with annotations of course.
>

It is important to realise, however, that without the mandatory
annotations it is extremely hard (impossible without a 'whole program'
analysis) to say whether a piece of code is written in SPARK or not.  It
is only the presence of annotations that makes, for example, aliasing
and function side effects (both prohibited in SPARK) detectable in
reasonable computation times or in incomplete programs.  The elimination
of errors at the coding stage is one of the factors that makes SPARK
use so cost effective; certainly it is better than waiting
until the code is finished and then trying to find errors
retrospectively.  Analysers (other than the SPARK Examiner of course)
which claim to check for SPARK  compliance only do very crude checking
for major prohibited constructs such as tasking or the use of "new".

Peter



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



  reply	other threads:[~2000-09-13 11:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-02 20:10 exiting a bloc Mathias Dolidon
2000-09-02 20:39 ` Mathias Dolidon
2000-09-02 21:01 ` Robert Dewar
2000-09-02 22:34   ` Mathias Dolidon
     [not found]     ` <86snrhkfep.fsf@acm.org>
2000-09-03 15:46       ` Mathias Dolidon
2000-09-05 17:52   ` Richard Riehle
2000-09-06  2:06     ` Ted Dennison
2000-09-06  9:41       ` Philip Anderson
2000-09-06 13:54         ` Ted Dennison
2000-09-06 21:10           ` Robert Dewar
2000-09-06 23:33             ` Ed Falis
2000-09-07  0:39               ` Robert Dewar
     [not found]               ` <39B72109.89DFAB8C@telepath.com>
2000-09-07 12:34                 ` Ed Falis
2000-09-08 10:33                   ` Ian Caldwell
2000-09-08 13:35                     ` r_c_chapman
2000-09-09  1:52                       ` Robert Dewar
2000-09-12 11:30                       ` Ian Caldwell
2000-09-12 20:13                         ` Robert Dewar
2000-09-09  1:48                     ` Robert Dewar
2000-09-12 11:24                       ` Ian Caldwell
2000-09-12 20:14                         ` Robert Dewar
2000-09-13  8:34                           ` Philip Anderson
2000-09-13 11:02                             ` Peter Amey [this message]
2000-09-06  7:00     ` Ray Blaak
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox