Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!microsoft!bobal
From: bobal@microsoft.UUCP (Bob Allison)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Summary: Type declarations, pretty long
Message-ID: <6105@microsoft.UUCP>
Date: 19 Jun 89 17:05:38 GMT
References: <2724@elxsi.UUCP>
Reply-To: bobal@microsoft.UUCP (Bob Allison)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 67

In article <2724@elxsi.UUCP> uunet!elxsi!corbett (Bob Corbett) writes:
>
>     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
> [...]

It turns out this is easily solvable: the kind parameter may be a parameter
(that is, a symbolic constant):

	INTEGER, PARAMETER :: MOST_INT_BITS = 64
	INTEGER(MOST_INT_BITS) :: entity-decl-list

However, it doesn't allow you to define a type, merely a type kind.  My
personal resistance to that feature (contrary to Walt Brainerd's assertion
that we're all morons who can't handle the concept) is that it doesn't mesh
well with the current rules of FORTRAN syntax: if we could define the first 
token in each statement of an explicitle separated declaration section to 
be a reserved keyword or a type (as in other languages which support this 
feature), then I wouldn't have any problem.  However, FORTRAN has enough 
areas already where the context just takes too long to resolve, and I am 
reticent to introduce more areas.

>
>     KIND selectors are an inherently implementation-dependent feature.  I have
> [...]  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.
>
> [...]
>						Yours very truly,
>						Bob Corbett

This is an entirely separate problem, and a fundamental weakness in the
KIND specifier: what does it mean?  Not only is it implementation dependent,
but it is in units that are implementation dependent.  In other words, 
you are best served by always using symbolic constants whenever using 
KIND parameters (which almost defeats their use).  

It can be argued that this is actually an aid to portability since it isolates
system-dependent parameters, and I admit to being on the fence for this
argument.  However, it introduces yet another need for MODULEs (since
that is the obvious place to put the declarations), which have become the
catch-all bucket for anything and everything.  Unfortunately, the source
of a MODULE is not necessarily lying around while you're trying to hand-
check the code.

Bob Allison
uunet!microsoft!bobal