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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,ec6f74e58e86b38b
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news2.google.com!news4.google.com!feeder.news-service.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!209.197.12.242.MISMATCH!nx01.iad01.newshosting.com!newshosting.com!novia!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!news-xxxfer.readnews.com!news-out.readnews.com!postnews3.readnews.com!not-for-mail
Message-Id: <4bfd9d39$0$2367$4d3efbfe@news.sover.net>
From: "Peter C. Chapin" <pcc482719@gmail.com>
Subject: Re: Lost in translation (with SPARK user rules)
Newsgroups: comp.lang.ada
Date: Wed, 26 May 2010 18:17:09 -0400
References: <op.vda45rsfule2fv@garhos>
 <0466e131-cc80-4db4-b080-eec9aefcb1c7@z17g2000vbd.googlegroups.com>
 <op.vda7dlc2ule2fv@garhos> <4bfd2d05$0$27598$ba4acef3@reader.news.orange.fr>
 <op.vdbug4sixmjfy8@garhos>
User-Agent: KNode/0.10.9
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit
Organization: SoVerNet (sover.net)
NNTP-Posting-Host: 082ca68a.news.sover.net
X-Trace: 
 DXC=Sh@`HlE2]>XJiEbTeh[P]ZK6_LM2JZB_SoW9MW8fWa][:WUUlR<856_L;TWA_637iT?N:hfMJWEUZ
X-Complaints-To: abuse@sover.net
Xref: g2news2.google.com comp.lang.ada:12060
Date: 2010-05-26T18:17:09-04:00
List-Id: <comp.lang.ada>

Yannick Duchêne (Hibou57) wrote:

> That is where I was not agree with a previous similar sentence from  
> someone else. I don't see a reason why only critical applications should  
> benefit of verifiability. This would not be a waste to apply standard  
> logic to program construction, and I even feel this should be an expected  
> minimum.

I think the reason is that it's hard. SPARK's restrictions exist, in part, to
create a language that can manipulated in a reasonably formal way using
current technology. As soon as you start adding back exceptions, dynamic
memory, recursion, etc, etc, it becomes very hard (beyond the state of the
art?) to say significant things statically in formal way. Yet those features
*are* very useful for many programs.

I know there has been a lot of work done in the field of static analysis and I
hope the field continues to advance. As it does, SPARK, or something like it,
may be able to take on some of the complicated features it currently avoids.
Also, depending on your needs, other kinds of static analysis might be useful
besides formally proving program properties. So what I'm saying is that it
may be premature to think about incorporating the SPARK sublanguage formally
into the Ada standard. SPARK is a tool... one of many. I look forward to even
better tools in the future!

For example take a look at this:

        http://www.adacore.com/home/products/codepeer/

I believe this tool works with full Ada and it sounds pretty neat. Disclaimer:
I haven't tried it.

Peter