Re: terminate applications

["Robert I. Eachus" <rieachus@attbi.com>]

Marin David Condic wrote:
> Interesting, but not compelling because it just plain isn't terribly 
> useful to the end user. If I want a simple call to shoot the entire 
> program in the head, I don't want to study the Suma Theologica for 
> several years to figure out what programming sin I committed that is 
> keeping it from doing the thing I want done. :-) If there is some 
> Theoretical Purity that must be maintained to task abortion, then so be 
> it. Give me a Ada.Kill ("-9") ; subprogram call that will do what I want 
> it to do - kill the program regardless of what the rest of it may be doing.

First, send a comment to Ada-Comment.  I believe the address is 
currently ada-comment@ada-auth.org.  I think you have a good case for 
some sort of an �berkill.

But note that this cannot and should not be the normal behaviour of 
aborting the environment task, or any task.  This is not ideological 
purity.  Think of it this way.  Using your �berkill on a program that 
interfaces to a database will not only kill the program, it will break 
transactions and corrupt the database.  Yes, cycling the power can do 
the same thing, but correctly written Ada programs will not, even if the 
main program is aborted.  (It will of course abort transactions in 
progress, which is fine.  But the (correct) use of abort deferred 
regions will allow the main program to be aborted cleanly without 
corrupting any external files.

So why provide your hypothetical �berkill?  Because programmers are 
human, programs have errors, especially during development.  And it 
would be really nice to have the �berkill so you could fix the error. 
(It would be nice if you got an error message telling you where the 
abort was hanging, but the debugger should give you that.)

> All too often, Ada gets herself wrapped up in trying to maintain some 
> sort of purity on some issue and totally forgets that someone out there 
> needs a job done. Just like my desire to get saturated math gets shot 
> down by those who insist its behavior is too ill defined for the 
> standard. So what? Let it be ill defined. Its use in reality has 
> beneficial effects as an error recovery mechanism. It gets used in 
> reality all the time. All Ada succeeds in doing by maintaining this 
> purity is to make itself less useful to the practitioner - who must now 
> find some butt-ugly way around the problem.

If you think there is that kind of shootdown, send your complaint, 
again, to Ada-Comment.  But there is not.  I would love to see an 
addition to Ada 0Y that made saturated math easier, and I think it can 
be made to happen.  But the process is that real users (you) send in 
requirements indicating real needs, and the ARG will try to propose a 
language extension to WG9 that satisfies that need.

In the case of saturated arithmetic, that might be a predefined 
saturated type, or it could be a solution to the problem of literals for 
otherwise private types, say:

    type Saturated is private range <>;
    type Modular  is private mod <>;
    type Rational is private digits <>;
or type Rational is private delta <>;

which would get rid of the predefined operations (other than assignment 
and equality) but keep the literals.  How would users tell the compiler 
how to map the literals into values?  That is the tricky part.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.