Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <3446@lanl.gov>
Date: 12 Sep 88 20:56:01 GMT
References: <379@quintus.UUCP>
Organization: Los Alamos National Laboratory
Lines: 57

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.
There are only two types of machine/system in productive use, those
that allow run-time exception handling within user code, and those
that don't.  The universal action taken by those that don't is to 
halt the offending process with a message. This does not allow 'garbage
results to go undetected' - in fact it doesn't allow garbage results
to go at all!

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.

> Giles is arguing that the present vicious circle should be maintained:
>     FORTRAN has no *standard* exception-handling scheme, so
>     architects say "we don't have to provide for non-standard features", so
>     computers are built where arithmetic is allowed to produce GARBAGE, so
>     exception handling is hard to do on some machines, so
>     FORTRAN has no *standard* exception-handling scheme.

If you've got a Fortran which produces exceptions without reporting it, 
you've got a broken Fortran.  The issue here is whether the user code
should be allowed to regain control after an exception occurs.  The
answer is _not_ a simple 'yes'.  

> It is time we told the architects that high-speed garbage is garbage.

Archetects already know this.  That's why exceptions either halt the
offending code, or generate a signal which interrupts the offending code.
Systems that don't do the later may have a legitimate reason for not doing
so.  Language definitions which _require_ the system to do the later
are _not_ universally portable.  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!).

A language-independent library standard could be developed to address these
points.  For those machines which don't allow user code to regain control
after an exception, the library could remain (and be a no-op).  This
would allow machine independent code to be developed (in more than one
language even!).  The alternative is to allow each language to specify
its own (different) method of handling this stuff.  Some standards (like
the ANSI C) won't allow the signalling mode to be optional, so the 
complete language may not be implementable on all machines (including
some that might be _very_ desireable for other reasons).  I opt for the
first choice.

J. Giles