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,2e71cf22768a124d
X-Google-Attributes: gid103376,public
From: gmckee@cloudnine.com (Gary McKee)
Subject: Re: Assertions (a different intent?)
Date: 1996/06/24
Message-ID: <ADF43817966867238@p1.denver2.dialup.csn.net>#1/1
X-Deja-AN: 161882593
references: <JSA.96Jun18142249@organon.com> <dewar.835121649@schonberg>
 <dewar.835306677@schonberg> <4ql1fv$5ss@goanna.cs.rmit.EDU.AU>
 <DtI7n4.Brz@world.std.com>
organization: McKee Consulting (Software Assessment)
newsgroups: comp.lang.ada
Date: 1996-06-24T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <DtI7n4.Brz@world.std.com>,
bobduff@world.std.com (Robert A Duff) wrote:

 > for these two cases.  Note that in *both* of these cases, the compiler
 > can optimize the following code based on the asserted "fact".  These
 > pragmas are really no different from constraint checks, which may or may
 > not be suppressed, and which can, of course, affect the behavior of the
 > program.
 > 
 > The third case that Robert mentioned -- an assertion that cannot affect
 > the behavior of the program in any way -- is quite impossible to define
 > in language terms.  It very well might be a useful thing, though.
---------------------------------------------------------------
Robert has explained how "Pragma Assert" actually works in GNAT and, no
doubt, it is useful as such. My own preference would be for something with
diametrically opposite semantics. 

In particular, I see "assertions", whatever the syntax, as being a tool for
specifying a program/subprogram in more detail and with more restrictions
then the language semantics permit. Such an interpretation would REQUIRE
that the compiler process them and raise exceptions when appropriate. The
design constraint is that such assertions "must always be true IF the
system is correct implemented".

I achieve this affect with a simple package of Assertion procedures,
exceptions, etc. Some examples of usage:

1) Verify a boolean relation between two incoming parameters to a reusable
component:
   assert (param-A > param-b);

2) Verify that a parameter to a reusable component is within a legal (but
non-contiguous) range (obviously, with syntactic changes):
   assert (param-a in (23..143) or param-a in (312..445) );

Other possiblities certainly exist. Such assertion semantics allow a
competent deigner to embed design criteria, assumptions, and expectations
in the executable code.