[J3] Consistency in conversion functions

[Kurt W Hirchert]

Some miscellaneous observations on this subject:

1.  INTEGER: Consistency can sometimes be in the eye of the beholder.  
In my programming, I have rarely needed multiple kinds of integers, and 
it has been more typical for me to convert between these kinds using 
assignment rather than a conversion function.  Thus, in my programming, 
INT has typically been an alternative to NINT, FLOOR, and CEILING (i.e., 
conversion of a real value to integer using various rounding rules).  In 
still rare circumstances, it might have been an alternative to AINT (the 
same rounding rule but keeping the representation real).  In all of 
these uses, INTEGER would have struck me as a very strange name for what 
I was doing.

2. COMPLEX: I think making COMPLEX an alias for CMPLX is a bad idea.  
Although programs using the gfortran COMPLEX intrinsic are considered 
nonconforming, it is still extremely unfriendly for a revision of the 
standard to break them, so this should be done only if there is a major 
benefit to be had, and in my opinion this issue does not qualify as 
major.  On the other hand, putting the gfortran COMPLEX (or something 
compatible) into the standard would likely address Jeff's consistency 
issue and allow those gfortran programs to be conforming, so that looks 
like good idea!  Note that CMPLX has a "wart" imposed by the requirement 
for being compatible with FORTRAN 77 -- (0d0,10d) is a double precision 
complex constant, but CMPLX(0d0,1d0) returns a single precision complex 
value.  To the best of my knowledge, COMPLEX does what CMPLX does except 
that this wart has been repaired.  Indeed, I suspect the gfortran 
definition of COMPLEX probably came from a J3 proposed COMPLEX intended 
to address the wart in CMPLX.

3. all of the functions mentioned: I should point out that at least half 
an answer to this issue has been a part of Fortran since Fortran 90 -- 
you can reference intrinsic procedures using any name you like by using 
the the renaming feature of USE.  For example, you could create a module 
like

module intrinsics
intrinsic ABS, ACHAR, ACOS, ACOSD, ACOSH, ...
end module intrinsics

and then in the program unit where you want to use names of your own 
choosing, you could write something like

use intrinsics, only: INTEGER => INT, COMPLEX => CMPLX

If you want to use your names in many program units, you could do 
something like

module my_intrinsic_name
use intrinsics, only: INTEGER => INT, COMPLEX => CMPLX
end module my_intrinsic_names

so you could just say

use my_intrinsic_names

in those program units.  [I believe this approach was first mentioned as 
a solution for programs that already had an array named SUM and wanted 
to add code using the SUM intrinsic.]

Using this kind of solution could be made easier either by making 
processors provide an intrinsic module like my intrinsics module above 
or by extending the renaming syntax to the INTRINSIC statement, e.g.

intrinsic INTEGER => INT

[If considering the latter, they might also consider putting renaming in 
EXTERNAL and interface blocks.]

The beauty of facilitating this approach is that it helps keep J3 out of 
arguments about which names should consistent with each other, which 
should be made long to avoid conflicts, which should be kept short to 
make them easier to write, etc.

-Kurt