Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <3501@lanl.gov>
Date: 13 Sep 88 21:30:34 GMT
References: <390@quintus.UUCP>
Organization: Los Alamos National Laboratory
Lines: 169

From article <390@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe):
> 	- the possibility of the program *substituting* a *different*
> 	  calculation in place of the faulted one.  (Think "recovery
> 	  blocks".)

This assumes that the original code (which generated the fault) hasn't
changed the data while it was executing.  Most real applications don't
have that kind of memory.  Numerical codes (like off-the-shelf FFTs)
usually update their data in place.  By the time you get back to re-execute
the code with your *different* calculation, the data has been changed.

Now, recovery blocks work completely differently.  A explicit 'snap-dump'
is take at intervals and, if the code has an exception, you explicitly
go back to the context of the most recent dump.  This can be done without
the user having exception handling code.  If nothing else, it can be
done by hand.

> Well, the "remedial activity" might be deleting scratch files (very
> common), logging the failure, and then exiting.  I wouldn't have thought
> of calling this "a fix-up", but what do I know?

Deleting scratch files (and other such destructive habits) are _VERY_
bad ideas.  The cause of the exception might be contained in that scratch
file.  By deleting it, you have destroyed valuable evidence to the
user in finding the cause of the fault.  Having worked as a programming
instructor at university, I know first hand the painful lessons learned
from arbitrarily 'cleaning-up' the files when an exception occurs.

Logging the failure is done by the system, so is exiting.  What you want
here is something other than the default method of logging and exiting.

> Well, it's a couple of years since I saw a Fortran standard, but as I
> recall it, the response of a Fortran processor to errors is "undefined".
> Giles might call a Fortran processor which doesn't report errors broken,
> I might call it broken, but neither of us can call it non-standard.

Since this is a C VS. Fortran discussion, I guess that you're saying
C doesn't have this fault.  (Quick - why is x<<32 different from x<<16<<16
on a VAX in C - it's undefined, that's why!)  Yes, I call a Fortran 
which doesn't report overflow (or whatever) 'broken'.  I call C with
the above parenthetical problem 'broken' too.  

>>Insisting that all machines should do
>>the latter may deprive users of significantly improved performance of 
>>correct programs just to allow a _very_slight_ convenience for incorrect
>>programs (imagine that, correct programs forced to run slower simply in
>>order that some user can produce a different-than-default termination
>>message for his wrong code!).
> 
> I am afraid that this really annoys me.
> Let's see what assumptions we can find in it.
> (1) The only use of exception handling is to produce termination
>     messages.
I didn't make this assumption, it just happens to be one of the common
uses of exception handling (in fact - one of the _most_ common).
> (2) The only consumer of termination information from a program is
>     the user (that is, programs are never invoked by other programs).
Of course, controllers can catch the default termination message that the
system puts out - the executable need not be able to catch its own errors
for this capability.
> (3) There are non-trivial correct programs.
I don't know what this means.  If you're implying that a code which
deliberately generates (and recovers from) an exceptional condition
is 'correct', you have a strange concept of what correctness is.
> (4) Programs which meet their specifications can never get exceptions
>     due to data not covered in the specifications (the sentence quite
>     explicitly says that the cause of exceptions is "wrong >code<").
Exactly so.  I do claim that exceptions are errors.  That was the designed
purpose of exceptions.  For example, passing a negative argument to a
floating-point (not COMPLEX) LOG function is an *ERROR*.  Any code which
does so deliberately is not 'correct', even if it does what the user
intended.
> (5) No Fortran program ever does anything to its environment which
>     should be undone before termination (no scratch files, no numerically
>     controlled tools, no screen blanking, ...)
The assumption _you're_ making here is that all this termination clean-up
isn't going to obscure the cause of the fault.  It often does.  It's a
bad idea: a) to have any files, tools, or screen modes which can't be
undone manually; and b) to do any of such things automatically in an 
error state.
> (6) The only people who matter are the people who want top performance;
>     people who are trying to write _reliable_ systems don't count.
Reliable systems are ones which don't produce _wrong_ answers.  What
you seem to want are systems which continue to run after errors have
occured (and you _assume_ that your exception handler works correctly).
What you want is not necessary for reliability.  What you want _may_
improve robustness (or, maybe not - who wrote your exception handler?).
Robustness is something that can be traded-off against performance.
You are the one that is claiming that only one type of person matters:
those who crave your brand of robustness.  I never said that designers
should not consider your type of exception handling - I said that there
might be legitimate reasons for excluding it in some designs.
> (7) End-users don't matter (the sentence quite clearly assumes that
>     producing a "different-than-default termination message" is not
>     important).
It may, or may not, be important.  The degree of importance should be
traded off against other considerations (like performance).  _YOU_ are
the one who wants the standard to _require_ a particular type of 
exception handling.  I maintain that the language standard should only
require those things which are necessary to the proper use of the
language.  Reliable code _can_ be written _without_ user controlled 
exception handling.  This is _not_ the province of language standards.

> [...]                   I will go so far as to say that if the
> only use of exception handling _were_ to produce termination messages
> that the end-user could understand, that would be sufficient warrant
> for requiring it.

In a system with lot's of naive users and no particular performance
requirements, I'll agree.  In a system where the users are professionals
and their understanding of their programs and system is quite good,
I would argue that performance should take the upper hand.  Languages
which are only designed to work in _one_ of these environments and not
the other are not adequate for Numerical work (where there is _much_
of both kinds of work).  So, I still claim that the language is _not_
the place to standardize this stuff.
> 
> I also point out once more that my proposal would allow an implementation
> to say "no, I can't do this", which means that it would have *ZERO*
> performance impact when a program did not request exception handling.

No, your proposal would allow the language designers to say what _they_
wanted the implementation to do.  If _they_ say that the option "no,
I can't do this" is illegal in their language, then that's that!  My
proposal is that exception handling should not be in the language, but
in a seperate library.  In my proposal, there _is_ the choice available
to the implementor to say "no, I can't do that".  The implementor can
say that, and _still_ be standard conforming (for those languages which
aren't already damaged by including other requirements). 

>>A language-independent library standard could be developed to address these
>>points.
> 
> Let's see it!  Don't forget, there's ADA, APL, BASIC, C++, COBOL, FORTRAN,
> LISP, ML, MODULA-2, PASCAL, PL/I, SIMULA, Smalltalk-80, ...

I said 'language-independent' not 'universal'.  It is clearly desireable
for Fortran, Pascal, C, and Modula-2 (and any other procedural languages
you happen to have) to be able to call each other in the same program.
In such a context, the exception handler could be written in one of the
above - or in assembly - and be usable for all the others.  I claim that
this is a _much_ better solution than letting each language committee
decide on their own.  And, if my solution is standardized, it would
be portable as well.
> 
>>The alternative is to allow each language to specify
>>its own (different) method of handling this stuff.
> 
> THIS HAS ALREADY HAPPENED!  [...]

That doesn't make it a good idea!!  By your logic, language designers
should never even _try_ to learn from the mistakes of others.

> There are at least two kinds of programs:
> (s) programs for wizards (yourself, other people in your group, certainly
>     noone who lacks access to the source code or wouldn't understand it).
> (o) programs for mortals (especially programs written for sale to people
>     who do not get the source code).
> I get the impression that Giles is thinking in terms of (s), while I am
> thinking in terms of (o).  [...]

No, I'm thinking in terms of _BOTH_.  I know, flexibility is a novel
idea.  YOU'RE the one who claims that language standards should exclude
one of these two groups.  I say, make the language cater to both groups,
and if group (o) needs additional features, define them independently
from the language.

J. Giles
Los Alamos