(j3.2006) (SC22WG5.4907) [ukfortran] Comment on a comment on the WG5 letter ballot on N1947

[Craig Dedo]

> -----Original Message-----
> From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org]
> On Behalf Of Bill Long
> Sent: Thursday, January 17, 2013 08:07
> To: sc22wg5
> Subject: (j3.2006) (SC22WG5.4907) [ukfortran] Comment on a comment on the WG5
> letterballot on N1947

	<snip>
 
> Indeed. I much prefer a "default64" switch that does both integer and
> real, as opposed to the independent-r8 / -i8 style switches.   It would
> be even better for the programmer to not use default integer or real
> declarations, but include specific KIND parameters.  Unfortunately it is
> hard to change old habits.  As an example, the brand new MPI 3 Fortran
> interface still uses default INTEGER declarations.
> 
> Cheers,
> Bill
> 
> --
> Bill Long                                           longb at cray.com
> Fortran Technical Support    &                 voice: 651-605-9024
> Bioinformatics Software Development            fax:   651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

	I wholeheartedly agree with Bill Long's comment about explicitly using KIND type
parameters on all data declarations, both for variables and for named constants.

	Like many other Fortran programmers, I have developed a module of definitions that
are useful for a wide variety of application area.  I call my module Common_Definitions_M.
In it, I include definitions for all of the kind type parameters for real and character
kinds.  I also use all of the definitions in the intrinsic ISO_Fortran_Env module.  

	In the part on real kind type parameters, I define named constants SP, DP, and QP
for Real32, Real64, and Real128, respectively.  Also the same for R4, R8, and R16.  Since
I do most of my work on the Intel processor, I also define a named constant Real80 to
represent the Intel 80-bit floating point representation and equate that to the named
constants R10 and XP (for eXtended Precision).

	In the part on character kind definitions, I have named constants for ASCII, UCS2,
and UCS4.

	I have not yet defined named constants for integer kinds, but I suppose I could
(maybe even should) define them in parallel to the definitions for real kinds.

	I am strongly opposed to using compiler options to "promote" the definitions of
default kinds.  Such practices silently change the semantics of the source code.
Fortunately, I have never worked in a shop where I was required to use such practices.  I
find it much more useful to rigorously use kind type parameters in all cases.

Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                  Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo