jlg@a.UUCP (Jim Giles) (03/22/88)
> 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
cdb@hpclcdb.HP.COM (Carl Burch) (03/26/88)
> > 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