Is it time to legitimise REAL*8 etc?

I whether anyone else would agree that it may be time to legitimise the
usage of data declarations of the form REAL*8, INTEGER*2 etc

I'm fully aware of the importance of making programs portable, as I have
written Fortran in the past on machines with word-lengths of 12-bits and
72-bits, and an awful lot of word lengths in between. Thus I can see
why the Fortran 90 Standard introduced the kind selection functions,
given the wide range of processors in the 1980s.

But the current situation is a bit different.

(1) There's a huge amount of Fortran still in active use which uses
REAL*8 etc, and in such programs this is the major (sometimes the only)
feature which makes the code non-Standard. I have sometimes pointed out
to programmers who still use this notation that they really ought to use
something more compatible with the Standard, but I don't think I have
got many converts. Unfortunately the simplest change: altering
REAL*8 variable
to
DOUBLE PRECISION variable
don't actually help much: it makes the code Standard-compliant, but the
two forms don't necessarily mean the same thing. Few programmers that I
know seem to be convinced that they ought to write something like
REAL(KIND=SELECTED_REAL_KIND(15,99)) variable
because that is so cumbersome and hard to read. (Of course you can
simplify a bit by using a named constant for the kind, but that adds
extra statements, so programmers are still reluctant).

(2) Processors which are not byte-oriented seem to be extinct, and
IEEE-754 floating-point processing on 32-bit and 64-bit processors now
reigns supreme. I think it can be argued that on a byte-oriented
machine REAL*8 is a more concise and more accurate specification of
one's need for an IEEE-754 64-bit floating-point variable, than the
notation using SELECTED_REAL_KIND, where the arguments are often chosen
somewhat arbitrarily. The reader of code has to think "hmm, the first
argument is more than seven, so the programmer probably wants IEEE
double precision here". The notation really isn't very readable.

(3) All current compilers seem to accept REAL*8 and similar without
problems for obvious reasons of compatibility with existing code, though
a few emit warnings if you set the right switches. So there's obviously
no difficulty in writing compilers which can accept the notation
alongside the kind-oriented functions.

I don't know if it's too late to send in a comment suggesting an
appropriate amendment to the Fortran 2008 specification?

What do people think?

--
Clive Page
.

Relevant Pages

  • Re: Uninitialized variables
    ... I used Algol 60 and Fortran. ... 3) a standard "graphics" library for workstation ... > Programs for Programmers - QA, Compilers, Graphics, Consultancy ...
    (comp.lang.fortran)
  • Re: Is it time to legitimise REAL*8 etc?
    ... why the Fortran 90 Standard introduced the kind selection functions, ... to programmers who still use this notation that they really ought to use ... something more compatible with the Standard, but I don't think I have ...
    (comp.lang.fortran)
  • Re: Uninitialized variables
    ... I used Algol 60 and Fortran. ... all programmers would have debugging and error-checking ... standard and doing things that are illegal in a technical ...
    (comp.lang.fortran)
  • Re: Is it time to legitimise REAL*8 etc?
    ... why the Fortran 90 Standard introduced the kind selection functions, ... to programmers who still use this notation that they really ought to use ... something more compatible with the Standard, but I don't think I have ...
    (comp.lang.fortran)
  • Re: My philosophy
    ... Know the standard; many problems are caused simply by programmers being unaware of the standard. ... This confuses two themes (pass control to calling routine which is an executable statement, and this is the last statement of this routine, which is not), and suggests woolly thinking by the programmer. ... on the same theme, don't use a FORTRAN 90 peculiarity if you can do it equally well in FORTRAN 77. ...
    (comp.lang.fortran)