Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!beta!a!jlg
From: jlg@a.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Fortran 8x, COMMON, SAVE, minus zero
Message-ID: <523@a.UUCP>
Date: 22 Mar 88 11:37:21 GMT
Distribution: na
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 54
Keywords: Fortran 8x standard, deleted features


> The criterion for Fortran 8x features (in my opinion) should be to
> certify existing practice or to extend the language in a significant
> way.  I will use this criterion throughout this discussion.

One of the problems with the Fortran 8x standard is that the committee
decided to leave the 'deleted features' section empty.  There are several
problems with the Fortran 77 standard that should have been addressed
right away.  I'm not talking here about the fundamental features of older
Fortran that are in the deprecated features list but of small 'errors' in
the last standard.  I will talf of two of them here.

The first is that Fortran 8x should specify that COMMON blocks are SAVEd
by default and the standard should provide some syntax for explicitly
'unsaving' common blocks (if anyone really thinks it's important).  I
have not seen any Fortran implementations which treat COMMON blocks as
automatic or stack variables.  COMMON blocks behave as if they were SAVEd
in all Fortran environments I've seen.  Furthermore, one of the most
important uses of COMMON blocks is to pass information between
subroutines without the caller of these routines needing to provide for
this data.  Though technically nonstandard already, many users still rely
on this method of passing information without SAVE statements.  In fact
many users are still unaware that SAVE can be applied to COMMON blocks!

Naturally, if COMMON is automatically saved, so should be its replacement.
Therefore, the global variables (both private and public) declared in a
MODULE should be SAVEd by default (again with explicit 'unsaving' if
somebody thinks it's important).

The second problem is that Fortran (both 77 and 8x) do not allow a minus
sign to be output as part of the representation of a number that prints as
zero.  This is, for most people, a very minor problem.  But, for some
numerical analysts this could be an important issue.  If the number is
negative, but underflows an F-format field, the current Fortran rule
requires that not even the sign of the number should be printed correctly!
Furthermore, many machines (all IEEE floating-point standard machines)
require the existence of an internal 'negative zero' which has specific
numerical meaning in some operations.  One type of work that this is
 particularly important to is interval arithmetic.

The reason that Fortran doesn't allow negative zero to be printed is
that to do so would contradict ANSI X3.42-1975 which is the standard for
representation of numeric values as strings.  I think in this case that
the needs of the numerical analysts should outweigh the contradictory
standard (especially with Fortran).  Note: Fortran 66 allowed negative
zeros.

Neither of the above two changes would make the slightest difference to
any existing Fortran program, and little to most users.  For this reason
I think they could be made right away - without going through the inter-
mediate step of 'depricated feature'.

J. Giles
Los Alamos