Path: utzoo!mnetor!uunet!husc6!ncar!ames!pasteur!ucbvax!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclcdb!cdb
From: cdb@hpclcdb.HP.COM (Carl Burch)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 8x, COMMON, SAVE, minus zero
Message-ID: <6690015@hpclcdb.HP.COM>
Date: 26 Mar 88 02:35:03 GMT
References: <523@a.UUCP>
Organization: HP ITG/ISO Computer Language Lab
Lines: 31

> 
> 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 talk of two of them here.
> 
> ...
> 
> 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 'deprecated feature'.
  
    Removing restrictions like the one that says negative zeroes will
not be produced need not go through the obsolescence cycle - only features
which will cause currently standard-conforming programs to become nonstandard.
Another example in this general area (which I sponsored) is the allowing of
RECL in the OPEN statement for a sequential file.  This was illegal under
FORTRAN 77, but will cause the processor to open a file that allows records
of at least the specified length (assuming the question is even relevant, e.g.,
UNIX (tm, etc.)).  Since no standard-conforming program can have such a
feature, it need not go through the removal process.

    Since negative zeroes are allowed on input, it is difficult to see how
a serious program could depend on their not being produced on output.
The issue you raise of the representation standard is probably a more 
serious problem.
							Carl Burch
							HP Fortran