The one thing I don't like about Fortran is not the "%" (I don't
often use derived types anyway) but the fact that default real seems
to be converging on four bytes. In F77 days I used only
DOUBLE PRECISION with all real literals with a D exponent. That was
ugly then, but in F90 I explicitly specify kind parameters for all
real literals (not really all, I use "2" instead of "2.0_rk").
Fortran is supposed to be for number crunching, but the most
convenient default real can not be trusted.

The situation can be fixed (in decades time) by enabling somehow
the configuration of default real type. Google shows that this
point has been brought up several times before, but was not persued
further because it was just too much bother.

I think the simplest way to do it is to separate default real type
 from the special storage association rules it has with the other
default types, and then enable specification of the default real
kind parameter value (from outside the program) by processor
dependent means. Default integer and logical (and much less
default character) are not touched. I just don't see much use in
configurable default integer types.

I'd like to hear other people's thoughts on this before I write
this up into a proposal. So here's the idea (sorry it's kind of
longish):
-----
Summary of current state:
1. Fortran standard does not specify precision of real kinds. The
  standard does specify that double precision real must have more
  precision than default real and that double precision real occupy
  twice the storage unit of default real. Default real/integer/logical
  occupy the same storage unit.
2. Most (if not all) current processors support 4-byte reals (details
  of implementation vary from processor to processor).
3. All current processors support 8-byte reals (details of
  implementation vary from processor to processor).
4. Some current processors support real kinds larger than 8 bytes.
5. To ensure maximum portability of a program, a named kind type
  parameter is supplied to all REAL specifications and literals. Some
  conversion intrinsics (REAL, CMPLX) also require specification of
  kind type parameter.
6. Default real is converging on 4 bytes, i.e. many processors choose
  4 bytes as default real and there is pressure for other processors to
  adopt that default size due to portability reasons.
7. Consequently, double precision real is converging on 8 bytes.
8. Most (if not all) current processors have options to change
  precisions of real kinds from the processors' default. They may be
  offered as portability aids (for porting programs written for
  processors with different precisions for default real), or they may
  be offered as coding aids (for auto-converting programs written for
  one precision to another precision). Details of these options vary
  considerably from processor to processor.
9. There are many applications typical of Fortran where 4-byte real
  does not offer enough precision.
10. Popular languages other than Fortran have chosen 8-byte reals for
  their "default".

What I think:
1. Having to specify kind type parameters for all real literals
  unnecessarily clutters programs.
2. If the default real could be assumed to have at least 8 bytes,
  there won't be a need to specify kind type parameters for all real
  literals (for most problems, the default would simply be enough).
3. The means to make default real 8 bytes is available on most (if not
  all) processors as compile options. However, the detailed effect of
  such options vary from processor to processor so that they cannot be
  depended on for portable programs.

What I propose to do to the standard:
1. Introduce a "compatibility" real kind that must be supported by all
  processors. The compatibility real kind assumes all the special
  storage association rules given currently to the default real kind.
2. The default real kind is stripped of any special status other than
  being the default. Instead, default real kind is chosen to be either
  compatiblity real or some other real kind by processor defined means.
3. One way of how changing the default real kind affects rest of the
  language is worked out, so that this feature can be portably used.

How this affects existing and future processors.
1. Existing processors need no modification to comply to this revision
  (other than in accompanying documentation). The processor can simply
  be said to always chose the compatibility real kind for default.
2. A future processor might offer compiler options that implement
  this "standard" way of specifying precision for default real, along
  with other options that the processor already has.
3. Further into the future, the default default real might be changed
  to some kind other than the compatiblity real kind. There will be
  compiler options that change the default back to the compatiblity
  kind.

Things that must be decided:
1. A name for the "compatibility" real kind. Throughout this text I
  use the term compatibility real kind to refer to a real kind with
  special storage association properties currently given to default
  real. A better name is probably needed.
2. Should specific names of intrinsic functions be for (configurable)
  default real or compatibility real? I think the latter is better as
  specific names are mostly used in compatibility with older code.
3. Should different program units be allowed to have different kinds
  for default real? Yes. We need to link legacy code with new code.
4. What to do with default integer or default logical? I say there is
  no need to change them.
5. And what to do with default character? I say don't change.
6. The following proposed changes make special storage association
  simply not work when the default real is changed. Changing size of
  default real does not automatically change size of any other types
  unlike some portability compiler options. Is that OK?

Where to change:
1. In section "4.4.2 Real type", F2003 says
  > If the type keyword REAL is specified and the kind type parameter
  > is not specified, the default kind value is KIND (0.0) and the type
  > specified is default real.
  Prior to this, the existence of "compatibility" real kind must be
  stated, and then following this statement, "the default real kind is
  either the compatibility real kind or some other real kind specified
  by processor defined means" could be added.
2. In the same section,
  > The decimal precision of the double precision real approximation
  > method shall be greater than that of the default real method.
  is changed to refer to compatibility real instead of default real.
3. Wording in section "4.4.3 Complex type" does not change but
  introduction of the term compatibility complex type might be added.
4. The following state special storage association rules for default
  real and default complex. These should be changed to refer to
  compatibility kinds.
   a) constraints C580 and C583, and NOTE 5.37 (EQUIVALENCE rules)
   b) 5.5.2.3 Common association
   c) 12.5.2.4 ENTRY statement
5. "13.6 Specific names for standard intrinsic functions" lists the
  argument types for intrinsic functions' specific names. Default real
  and default complex here should be changed to refer to compatibility
  kinds.
6. "13.7.33 DPROD(X,Y)" states DPROD works on default real types.
  This should be changed to refer to compatibility types.
7. (1) and (2) of "16.4.3.1 Storage sequence" assigns numeric storage
  units to default real and default complex. These should be changed to
  refer to compatibility kinds.
8. (2) in "16.4.3.3 Association of scalar data objects" state special
  partial association rules for default real and default complex.
  These should refer to compatibility kinds instead.
9. (13) and (14) of "16.5.5 Events that cause variables to become
  defined", and (1) of "16.5.6 Events that cause variables to become
  undefined" state special partial association rules between default
  real and default complex kind. These should refer to compatiblity
  kinds.
10. "numeric storage unit" and "unspecified storage unit" in the
  glossary refers to default real which should be changed to refer to
  compatibility kind.
11. If different program units can have different kinds specified for
  the default real, that fact might be stated somewhere.

Where not to change:
1. In "4.4.3 Complex type", a complex literal with both parts integer
  is defined to be default complex type. This should be left as is
  (rather than change it to compatibility complex).
2. In NOTE 5.1, there is an example of a default real declaration,
  which should not be changed to refer to compatibility real.
3. In "5.3 IMPLICIT statement", the default mapping of (A-H,O-Z) to
  default real is stated. This should not refer to compatibility real.
4. NOTE 7.11 refers to a default real X as an example. This need not
  be changed.
5. "13.7.20 CMPLX(X[,Y,KIND])" specifies that omitting KIND results
  in default complex. This should not be changed (CMPLX(X,Y) results
  the "current" default complex).
6. The example in "13.7.59 KIND(X)" refers to default real.
  This should not be changed.
7. "13.7.97 REAL(A[,KIND])" specifies that omitting KIND results in
  default real. This should not be changed.
8. The example in "13.7.106 SELECTED_REAL_KIND([P,R])" refers to a
  default real approximation. This need not be changed.
9. "14.10 Specifications of the procedures" assumes IEEE arithmetic
  for default real in the examples. This need not be changed. Specific
  references to default real appear in 14.10.17, 14.10.23, and
  14.10.34. These also need no change.

Clarification:
1. What this attempts to do is to allow specifying (outside the
  program) a kind value for default real. It can be specified to be
  the compatibility kind (this is the only option on all existing
  processors) or some other kind. This "option" does not attempt to
  change the associated representations for individual kind values. It
  also does not attempt to change kind values for anything other than
  default real (no automatic promotion of default integer or double
  precision real).
2. Features left in for compatibility (such as DOUBLE PRECISION,
  DPROD, specific names for intrinsic functions, storage association)
  work only with compatibility kinds. Their use is not extended to the
  configurable default kind.
3. Defaults for conversion functions REAL and CMPLX, and the automatic
  conversion of integer complex literals are to the "default" kind not
  the compatibility kind.
4. The processor is not required to make available all supported real
  kinds for default real. A processor may choose to support only the
  compatibility real kind for default.
5. Changing the default real breaks only "special" storage
  association, i.e., that between different default types. "Good"
  practices like all COMMON blocks having the same mapping are not
  affected. What it breaks is storage association between different
  default types, and partial association between default real and
  default complex.
6. For linking new code with old, the old code using special storage
  association rules can be compiled with default real set to the
  compatibility kind, and the new code compiled with some other
  default real. The new code will use explicit kind type parameters
  specifying compatibility kind to access the old code.
-----
and that's it. Thanks
--
Yasuki Arasaki
[log in to unmask]