Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!aeras!elxsi!beatnix!corbett
From: corbett@beatnix.UUCP (Bob Corbett)
Newsgroups: comp.lang.fortran
Subject: dpANS Fortran 8x
Message-ID: <2724@elxsi.UUCP>
Date: 9 Jun 89 03:37:22 GMT
Sender: news@elxsi.UUCP
Reply-To: uunet!elxsi!corbett (Bob Corbett)
Distribution: usa
Organization: ELXSI, San Jose
Lines: 60


     One feature of Fortran 8x I find particularly annoying is that the type
definition facility permits only record types to be defined.  The lack of a
general type definition mechanism becomes even more irritating now that KIND
selectors have been added to the language.  Suppose a machine supports 64-bit
integers.  The Fortran 8x implementation for such a machine might permit
64-bit integer entities to be declared with a syntax such as

		    INTEGER(64) :: entity-decl-list

The number 64 is the kind selector.  Suppose a programmer is trying to write
a program for several different machines, and he or she has lots of data
object declarations for objects he or she wishes to be of the largest supported
integer type.  If the language supported a general type definition facility, he
or she could place a definition of a type, say LONGEST_INT, in an INCLUDE file,
and then use that type wherever it is needed.  The closest the current draft of
the standard will allow him or her to come to that solution is to allow a
definition of a structure containing a single field of the longest integer type.
The definition might take the form

			TYPE LONGEST_INT
			    INTEGER(64) V
			END LONGEST_INT

The data objects could then be declared using type declarations of the form

		    TYPE(LONGEST_INT) :: entity-decl-list

The problem with this approach is that to reference the data objects,
component selectors must be used.  For example, to increment a variable I
of type LONGEST_INT, the programmer would have to write

		             I%V = I%V + 1

There has got to be a cleaner way.  Some of the more exotic programming
languages, such as C and Pascal, allow type definitions for arbitrary data
types.  I think X3J3 would do well to see how those languages manage to handle
this apparently difficult concept.

     KIND selectors are an inherently implementation-dependent feature.  I have
no objection to adding implementation-dependent features to a language, but I
feel they should be clearly marked as such.  The draft standard requires a
conforming processor to contain the capability to detect and report the use of
kind type parameters not supported by the implementation.  This requirement
seems a bit weak.  I can easily imagine

		              INTEGER(8)

meaning an 8-bit integer in one implementation, a 48-bit integer in another,
and a 64-bit integer in another.  The requirement should be strengthened to be
the capability to detect and report all uses of KIND selectors.

      The use of KIND selectors for integer types is distasteful, since a
range mechanism could provide the same capability in a portable way.  However,
given that no similar mechanism will work for character, logical, and
floating-point data types, consistency argues for the use of KIND selectors
for integers as well.

						Yours very truly,
						Bob Corbett