Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!unm-la!unmvax!brainerd
From: brainerd@unmvax.unm.edu (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Fortran 88 Parameterized Data Types
Keywords: fortran
Message-ID: <2066@unmvax.unm.edu>
Date: 23 Oct 88 19:45:12 GMT
Organization: University of New Mexico at Albuquerque
Lines: 119


After climbing to Sandia crest on a beautiful day yesterday
and going to an NMSO concert of Mozart and Stravinsky last night,
I am ready to forget about all the political garbage that appeared
recently and provide some technical information for those interested.

Comments from the public on the draft proposed Fortran 88 included
the following:

1.  The features for control of numeric precision are too complicated.

2.  A facility for manipulation of bits is needed.

3.  A "short integer" (and maybe a "long integer") data type is needed.

4.  A feature to handle multiple character sets, particularly those
    with large numbers of characters, is needed.

A single unified scheme proposed and accepted by ISO/WG5 in Paris
solves, to a large degree, each of these problems.  The solution is not
particularly elegant and certainly is not like Pascal or C, but should
be easy to learn and easy to implement.  A sketch of this scheme follows.

Each intrinsic data type (REAL, INTEGER, LOGICAL, and CHARACTER) has a
parameter, called its KIND, associated with it.  A KIND is intended to
designate a machine representation for a particular data type.

As an example, an implementation might have three REAL kinds, informally known
as single, double, and quadruple precision.  In Fortran 88 (as proposed),
the KIND is an integer, much like an I/O unit number; these numbers are
processor dependent, so that KIND=1, 2, and 4 might be single, double,
and quadruple precision, or so that KIND=4, 8, and 16 also could be used.
The requirements are that there must be two kinds, representing default
real and double precision, and that a representation with a larger KIND
value must have greater precision.  Note that the value of the KIND number
has nothing to do with the number of decimal digits of precision, as was
the case with the original proposed precision scheme.  One reason that this
new proposal simplifies the implementation is that it is up to the user to
make sure that actual and dummy arguments must match; there is no "passed in"
precision.

There is an intrinsic function SELECTED_REAL_KIND that produces the
smallest kind value whose representation has at least a certain precision
and range.  For example SELECTED_REAL_KIND (8, 70) will produce a kind
(if there is one) that has at least 8 decimal digits of precision and
allows values between 10 ** -70 and 10 ** +70.  This permits the programmer
to select representations having required precision or range, albeit in a
somewhat less direct manner than in the previous proposal.  Parameters
can be used effectively here:

PARAMETER (MY_PRECISION = SLECTED_REAL_KIND (8, 70))
REAL (KIND = MY_PRECISION) :: X, Y, Z

Of course, this can be even more effective when appearing in a module
that, in effect, defines a real data type with MY_PRECISION.  Then those
declarations can be included into any program unit, ensuring that required
declarations will be identical.

For the integer data type, things are pretty much the same, except that there
is only argument for the SELECTED_INT_KIND intrinsic.  For example,
SELECTED_INT_KIND (5) produces an integer type allowing representation
of all integers between 10 ** -5 and 10 ** +5.

For the CHARACTER data type, the implementation may include as many kinds
as there are character types supported.  This is an advantage over the
NCHARACTER (national character) proposal previously considered, in that
it allows for only one character set in addition to the default.  It may
well be that you want to have Chinese, Japanese, Arabic, and chemical symbol
character sets all in one program.  With this proposal you can, if you can
get your vendor to support them all.

Constants provide a problem.  There must be a way to specify constants of
various kinds in order to pass them as actual arguments and have them match
the dummy argument.  It has been proposed to put and underscore and a kind
after a constant (all of which is optional, of course).  To illustrate this
with characters:

PARAMETER (NAME_LENGTH = 20, KANJI = 3)
CHARACTER (LEN = NAME_LENGTH, KIND = KANJI)
   ...
NAME = '%*(#^&$'_KANJI

(Sorry if that doesn't look like Kanji on your screen.)

This proposal would allow some character strings to be stored in the standard
ASCII and some in EBCDIC if that were desirable.

PARAMETER (ASCII = 1, EBCDIC = 13)
CHARACTER (LEN = NAME_LENGTH, KIND = ASCII) :: NAME_A
CHARACTER (LEN = NAME_LENGTH, KIND = EBCDIC) :: NAME_E
   ...
NAME_A = 'GEORGE'_ASCII;  NAME_E = 'GEORGE'_EBCDIC

For the LOGICAL data type, the default kind and at least one other (KIND=1)
must be implemented.  There are no storage association requirements for
KIND=1, so the values may be stored as one bit, if desired, and as many bits
as is feasible may be stored in a word.  An implementation on a machine that
is byte addressable may make available a LOGICAL kind for which each bit
is stored in a byte, and a bit-addressable machine or one with excellent
shifting and masking instructions may have a LOGICAL kind for which
there is a value stored in each bit of a word or byte.  And, of course,
all of the above may be available in one implementation.  What is usually
thought of as a "word" of bits can be represented as an array of logicals
of KIND=1.  Of course, the .AND., .OR., and .NOT. operations are already
available for such arrays and so can be used to implement "bit" manipulations.
The proposal also includes ways of writing arrays of logicals ("bit strings")
as hexadecimal, octal, and binary constants.  It also includes B, O, and Z
edit descriptors.

Well, this is one thing that the awful "gang of five" was doing to respond
in a positive vein to the public comments while X3J3 was debating who should
be allowed to tell what to whom.  Let's have a rational discussion of this
and other technical issues.  Another important thing that was done was add
pointers; if you would like to see a sketch of the pointer feature proposed,
say so, and it might be arranged.  Most of the members of X3J3 seemed to like
the pointer proposal when it was presented.

=============================================================================
Walt Brainerd, Unicomp, Inc., 505/275-0800, brainerd@unmvax.unm.edu