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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,2c6139ce13be9980
X-Google-Attributes: gidfac41,public
X-Google-Thread: f43e6,2c6139ce13be9980
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 103376,3d3f20d31be1c33a
X-Google-Attributes: gid103376,public
From: Ken Garlington <keg0@flash.net>
Subject: Re: Safety-critical development in Ada and Eiffel
Date: 1997/07/12
Message-ID: <33C831CE.4E56@flash.net>#1/1
X-Deja-AN: 256511333
References: <ED2MuF.4n6.0.-s@inmet.camb.inmet.com> <ED3E9M.F0u@syd.csa.com.au>
 <01bc8d8c$e608b740$6bb32399@default> <33C5B971.7845@erols.com>
Organization: Flashnet Communications, http://www.flash.net
Reply-To: keg0@flash.net
Newsgroups: comp.software-eng,comp.lang.ada,comp.lang.eiffel
Date: 1997-07-12T00:00:00+00:00
List-Id: <comp.lang.ada>


Ted Velkoff wrote:
> 
> Ken Garlington wrote:
> 
> > I'm not sure what was in Ada83 that was omitted in Ada95; however, I have
> > noticed
> > that Eiffel examples posted in various places tend to have assertions that
> > are
> > fairly simple in nature (range checks), etc that are directly representable
> > in Ada.
> > Those that aren't tend to be easy to do with good Ada design using
> > exceptions (sort
> > of the same "good design principles" that you discussed using in Eiffel to
> > get
> > the features made explicit in Ada).
> >
> 
> There's a big difference between assertions and exceptions.
> 
> I think a sign that says: "Dangerous curve ahead: left turn required"
> (precondition)
> 
> is much more useful than one that says: "Accident zone ahead"
> (exception declaration)

However, compare and contrast:

(ada-ish): type Foo_Type is range 1 .. 10;
           procedure Do_Something ( X : in Foo_Type );

(Eiffel-ish): procedure Do_Something ( X : in Integer );
                require X > 0 and X < 11;

Doesn't seem to make a lot of difference to me, although of course I
get to reuse Foo_Type in a lot of static contexts.

As to the more elaborate checks:

       procedure Do_Something (X : in Integer);

       X_Error : exception;
         -- raised if X does not meet precondition Complex_Precondition;

is not particularly more difficult to understand than:

     procedure Do_Something (X: in Integer);
       require Complex_Precondition(X);

The key is to have the external view of these assertions documented, and
to have
violations of those assertions cause certain effects in the system. Ada
has done more
than an adequate job in this area for our safety-critical systems. I
don't
need more of this; I need more static analysis tools (as the Safety and
Security Annex provides the foundation to support) and more efficient
code,
since safety critical embedded systems usually have a lot of
requirements
that preclude using the latest and greatest hardware.


> 
> -- Ted Velkoff