Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <390@quintus.UUCP>
Date: 13 Sep 88 08:56:51 GMT
References: <379@quintus.UUCP> <3446@lanl.gov>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 139

In article <3446@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <379@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe):
>> 
>> You are putting words in my mouth.  I DO NOT BELIEVE IN "FIXING-UP".
>> All I want to know is whether an exception occurred. [...]
>
>No, that's obviously _not_ 'all you want to know'.  If that was all you
>wanted, you don't need _any_ mention of exceptions anywhere in any
>standard except to say that exceptions _always_ should halt the code.

Note that I have been quoted out of context.
Giles was saying that requiring exception handling in the standard would
not be a good idea because generating precise exceptions on some machines
(such as vector-processing ones) would be very costly.  His text seemed
to imply that this was necessary in order that the program could "fix up"
the mistake.

The point of my statement was that I do not want a PL/I-like scheme
where a faulting statement can be pinpointed and "corrected".

Let me try to be maximally clear.  What I want in an exception handling
facility is
	- notification *to the program* that an error (fairly broadly
	  identified) has occured *somewhere* within a particular region
	  of the code, that region potentially being quite large, and
	  precise location within the region not being important

	- the possibility of the program *substituting* a *different*
	  calculation in place of the faulted one.  (Think "recovery
	  blocks".)

>The only reason to allow run-time user control after an exception is
>to allow the user code to try some fix-up action.  Your demand for
>run-time exception handling directly implies that you have some remedial
>activity in mind.  Whether you choose to _call_ it a fix-up or not is
>beside the point.

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?

>If you've got a Fortran which produces exceptions without reporting it, 
>you've got a broken Fortran.

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.

For example, although programs generated by the VMS Fortran compiler
normally report integer overflow exceptions, programs generated by
"f77" (and even Sequent's "fortran") do not.  So adding *positive*
integers is allowed to *quietly* give you *negative* results.

>Language definitions which _require_ the system to do the later
>are _not_ universally portable.

***NOTHING*** is universally portable.
I pointed out in some detail that integer arithmetic is not "universally
portable".  Giles has not yet refuted this.
The proposition "a language definition should not require the system to
do anything which would not be universally portable" entails the
proposition "the very worst computer architect has more right to decide
what a language should look like than the people who want to use the
language".  An architect could tomorrow come up with a machine where
subroutine calling is outrageously expensive, and a company could market
the machine next week, and the "universal portability" rule would force
us to delete subroutines from our language standards.

>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.
(2) The only consumer of termination information from a program is
    the user (that is, programs are never invoked by other programs).
(3) There are non-trivial correct programs.
(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<").
(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, ...)
(6) The only people who matter are the people who want top performance;
    people who are trying to write _reliable_ systems don't count.
(7) End-users don't matter (the sentence quite clearly assumes that
    producing a "different-than-default termination message" is not
    important).

As a professional programmer I know that (1), (2), (4), and (5) are
factually false, cannot agree with (6) or (7), and would dearly like
to believe (3) but don't.  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.

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.

>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, ...

>The alternative is to allow each language to specify
>its own (different) method of handling this stuff.

THIS HAS ALREADY HAPPENED!  Putting an exception handling facility in
a Fortran standard won't make things worse!  (The kind of thing I want
could easily be compatible with ADA.)

If someone really wants super-high performance and is willing to put up
with non-standard or non-existence exception handling to get it, let
them use a non-standard language.  It is already the case that people
using "supercomputers" have been using non-standard Fortrans.  Why should
using a Fortran which has a non-standard exception system be any worse?
Let's face it, if you are after absolute top performance, you are likely
to introduce machine-specific stuff into your program anyway.

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).  If someone is writing a computational fluid
dynamics program for use within his own research group, exception handling
is not so important (but still good).  But someone who is writing a
linear programming package for use on PCs by students all over the country
[thank goodness I am _not_ doing that!] had better try to make it as
robust as possible.