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
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bd40601768eaf8fd
X-Google-Attributes: gid103376,public
From: Richard D Riehle <laoXhai@ix.netcom.com>
Subject: Re: 'constant functions' and access constant params (was Re: Array of
 Variant Records Question...)
Date: 1999/09/28
Message-ID: <7sr6gl$soc@dfw-ixnews19.ix.netcom.com>#1/1
X-Deja-AN: 530417563
References: <7r5vh3$imu1@svlss.lmms.lmco.com> <37d6a45c@news1.prserv.net>
 <eExB3.6$ZR.1146@news.wenet.net> <37d6ccb6@news1.prserv.net>
 <7r77i8$i08$1@nnrp1.deja.com> <37d7c116@news1.prserv.net>
 <7r8t21$ov5$1@nnrp1.deja.com> <37d822a1@news1.prserv.net>
 <7reg02$t83@dfw-ixnews6.ix.netcom.com> <37DE8D09.C863CBC9@rational.com>
 <7roohh$s6r@dfw-ixnews7.ix.netcom.com> <37e01168@news1.prserv.net>
 <7rp86o$c6h@dfw-ixnews3.ix.netcom.com> <37E18CC6.C8D431B@rational.com>
 <7rs8bn$s6@dfw-ixnews4.ix.netcom.com> <37e2e58c@news1.prserv.net>
 <7s9nd0$cbe@dfw-ixnews17.ix.netcom.com> <37e8e067@news1.prserv.net>
 <7sas3p$bfa@dfw-ixnews3.ix.netcom.com> <7sc6b6$c6m$1@nnrp1.deja.com>
 <7socka$6u4@dfw-ixnews19.ix.netcom.com> <7sqbt6$1la$1@nnrp1.deja.com>
Organization: Netcom
X-NETCOM-Date: Tue Sep 28  2:56:05 PM CDT 1999
X-Inktomi-Trace: sji-ca-cache 938548541 22139 209.109.234.48 (28 Sep 1999
 19:55:41 GMT)
Newsgroups: comp.lang.ada
Date: 1999-09-28T14:56:05-05:00
List-Id: <comp.lang.ada>

In article <7sqbt6$1la$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>Assertions written at the level of the language itself only
>fix a very small part of this problem. And if you talk
>about compiler-checked assertions, then you are reducing the
>level of the assertions to a trivial level that definitely
>does not begin to approach full specification (remember we
>are FAR from being able to mechanically check that a full
>formal specification matches an implementation in a language
>at the semantic level of Ada, such checks require a large amount
>of human intervention at the implementation level, e.g. adding
>proof assertions).

I agree with most of your observations here.  Even Bertrand Meyer,
advocate of "design by contract" through assertions, agrees that
we have not yet reached a point in software design where we can
rely on a compiler to "prove" the validity of an assertion.  Of
greater concern is that one can construct an assertion so complex
that no current theorem-proving software can guarantee its correctness.
As much as I agree with Parnas, Gries, Dijkstra, and Knuth about the
desirability of assertions, I continue to be skeptical of their
usefulness in large-scale software systems.  

>Furthermore, full formal specifications are often neither
>desirable (too opaque) nor practical (problem too complex),
>nor conceptually possible (try to formalize the idea of
>"nice error messages").

Once again, I mostly agree.  On the other hand, I have been
encountering some really interesting work in formal specifications
coming from the European computing community.  I don't understand
all of what I see, but what I do understand is impressive.  It is
that kind of work that makes me optimistic about the potential for
formal specifications in the future.  

The people who follow us in creating the equivalent of software a
hundred years from now will look back on what we are doing today
with the same regard we give mathematicians in the time of Charlemagne.

Richard Riehle
http://www.adaworks.com


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