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,1e5c102037393131
X-Google-Attributes: gid103376,public
From: Richard D Riehle <laoXhai@ix.netcom.com>
Subject: Re: Assertions
Date: 1999/05/18
Message-ID: <7hqe7m$q7i@sjx-ixn1.ix.netcom.com>#1/1
X-Deja-AN: 479242518
References: <3736D243.1EEBF1AB@globalnet.co.uk> <3736F549.E3DDCDEB@pwfl.com>
 <7h83lc$rd$1@nnrp1.deja.com> <3739CECA.6A49865B@averstar.com>
Organization: Netcom
X-NETCOM-Date: Mon May 17  6:02:46 PM PDT 1999
Newsgroups: comp.lang.ada
Date: 1999-05-17T18:02:46-07:00
List-Id: <comp.lang.ada>

In article <3739CECA.6A49865B@averstar.com>,
	Tucker Taft <stt@averstar.com> wrote:

>In any case, here is a strawman:
>
>   pragma Assert(boolean_expression [, string_expression]);
>

    In one of my JOOP columns I proposed going a little further,
    coming closer to the Eiffel model,

    pragma Pre_condition  (boolean_expression [ ... ]);
    pragma Post_condition (boolean_expression [ ... ]);
    pragma Invariant      (boolean_expression [ ... ]);

   with the further suggestion that we adopt Require, Ensure, and
   Invariant from the Eiffel language.

   One must be careful with assertions as pragmas.  It is quite 
   possible to declare a non-sensical assertion that is never 
   detected by the compiler.  When declaring assertions for a 
   derivation class, one can construct a boolean expression that
   holds for the root of the class but fails for some derived type.
   
   This is a fundamental problem with assertions.  The more conservative
   approach of Ada, in which every type is invariant tends to be more
   appropriate for safety-critical software.  If there were some way
   to formally prove, through a software routine, that an assertion 
   did not resolve to some completely silly set of propositions during
   the derivation process, we might be more inclined to depend on them.
   As things stand now, assertion pragmas, while a good idea on the 
   surface, could easily create more problems than they solve.

   I think we need to proceed with some caution in this area.  SPARK 
   does take a very conservative approach with assertions.  However, 
   SPARK does not support extensible derivation classes.  This eliminates
   one of the potential dangers of relying on assertions.  Am I being too
   cautious here?

   Richard Riehle
   richard@adaworks.com
   http://www.adaworks.com