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,fc050a66c3b5d87d
X-Google-Attributes: gid103376,public
X-Google-Thread: 1094ba,86e8c626be2471ae
X-Google-Attributes: gid1094ba,public
From: Geoff Bull <geoff@research.canon.com.au>
Subject: Re: F9X twister & ADA (was: n-dim'l vectors)
Date: 2000/04/13
Message-ID: <38F53816.3D1F28A6@research.canon.com.au>#1/1
X-Deja-AN: 610491565
Content-Transfer-Encoding: 7bit
References: <8cctts$ujr$1@nnrp1.deja.com> <38EA0440.1ECBC158@ncep.noaa.gov>
 <38ED4ECA.ADB698C9@sdynamix.com> <m2n1n6blie.fsf@vega.qnet.com>
 <38F28A85.53809F39@sdynamix.com>
 <ddxI4.14290$ei.611831@bgtnsc04-news.ops.worldnet.att.net>
 <38F2C1DC.5538F9F0@research.canon.com.au>
 <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net>
 <38F3D1D3.416B3493@research.canon.com.au>
 <85SI4.4008$fV.338113@bgtnsc05-news.ops.worldnet.att.net>
 <38F3F803.A4A56259@research.canon.com.au>
 <RkTI4.347$PV.13913@bgtnsc06-news.ops.worldnet.att.net>
 <38F41313.DAF90E74@research.canon.com.au>
 <r62J4.930$PV.52530@bgtnsc06-news.ops.worldnet.att.net>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@research.canon.com.au
X-Trace: cass.research.canon.com.au 955594739 9650 203.12.174.227 (13 Apr 2000
 02:58:59 GMT)
Organization: Canon Information Systems Research Australia
Mime-Version: 1.0
NNTP-Posting-Date: 13 Apr 2000 02:58:59 GMT
Newsgroups: comp.lang.fortran,comp.lang.ada
Date: 2000-04-13T02:58:59+00:00
List-Id: <comp.lang.ada>

James Giles wrote:

> >What about buffered io and user defined buffering?
> 
> Like all parts of the program's state, those are all still present
> *in* the debugging file.  You can inspect them there.

But I'd prefer it in a place defined by me!
I hate looking at core dumps and, thankfully, since using
Ada I *never* have to - same for Java. (when I was a C/Fortran I
lived in the debugger, I get the impression you are still stuck there )

In any embedded / real time context your proposal is just plain wrong.

Stop dead on exception would be difficult to implement if the
program is multithreaded or distributed across multiple machines?

> I think undocumented exceptions are clearly the ugliest way to
> accomplish this.

But there is nothing wrong with clearly documented exceptions?

> Any public property of a procedure which isn't
> explicitly declared - by direct requirement of the language
> definition - is probably a bad idea.

Are you saying this is ok:
(yes I know Start should return a boolean,
instead of raising an exception)

package Rocket_Motor is

   procedure Start;
   --  may raise Primary_Ignition_Failed

   Primary_Ignition_Failed : exception;

end Rocket_Motor;

package body Rocket_Motor is

   procedure Start is
   begin
      ...
   exception
      when Constraint_Error =>
         raise Primary_Ignition_Failed;
   end Start;

end Rocket_Motor;

with Rocket_Motor;
procedure Launch is
begin
   ...
   Rocket_Motor.Start;
   ...
exception
   when Primary_Ignition_Failed =>
      Fail_Safe; 
 
end Launch;

?
Are you just objecting to raising (e.g.) Constraint_Error?
If so, it would be reasonably easy to write an asis tool
to enforce this policy.


> How bare is the hardware?  If it's all
> *that* bare, it won't support I/O or exceptions either.

Bare = no OS.
Just the the language defined runtime + your program.