[J3] Generic interface for IEEE_SELECTED_REAL_KIND?
Steven G. Kargl
kargl at troutmask.apl.washington.edu
Wed Jan 2 16:34:02 EST 2019
On Wed, Jan 02, 2019 at 09:09:41PM +0000, Bill Long wrote:
>
> > On Jan 2, 2019, at 2:28 PM, Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
> >
> > 18-007r1, 17.10 starts with
> >
> > "For all of the procedures defined in the modules,
> > the arguments shown are the names that shall be used
> > for argument keywords if the keyword form is used for
> > the actual arguments.”
>
> Which is regarding how to write the syntax for a reference that uses keyword arguments, as in
>
> IEEE_SELECTED_REAL_KIND (P=6, R=30, RADIX=2)
>
>
> >
> > IEEE_SELECTED_RERAL_KIND is listed in Table 17.2 as
> > a module procedure available the from IEEE_ARITHMETIC
> > module. If a Fortran processor has 2 or more INTEGER
> > kinds (say, INTEGER(1) and INTEGER(2)), it is impossible
> > to write a generic interface for IEEE_SELECTED_REAL_KIND
> > that can be contained within the module. Is there a
> > J3 paper that discusses this issue?
>
> This is unrelated to the use of keyword arguments. I agree
> that writing a generic interface to cover all the combinations
> of KINDS for the integer arguments is very tedious, but why is
> it “impossible”?
If you have 2 or more INTEGER kinds, you end up with an
ambiguous interface as all arguments to IEEE_SELECTED_REAL_KIND
are optional. A brief example with integer(1) and integer(2),
module ieee_arithmetic
interface ieee_selected_real_kind
function one(p, r, radix)
integer one
integer(1), optional :: p, r, radix
end function one
function two(p, r, radix)
integer two
integer(1), optional :: p, r
integer(2), optional :: radix
end function two
!
! 6 more interfaces go here
!
end interface
contains
one() ! yada
two() ! yada
end module
program foo
use ieee_arithmetic
integer, i = ieee_selected_real_kind(6_1) ! Is this one() or two()?
end program foo
The above, of course, won't compile due to the ambiguity.
> There is a proposal for F202X for templates that would make
> writing this sort of module procedure trivial, not needing a
> generic interface. In fact, writing the IEEE modules in Fortran
> would be significantly simplified if templates could be used.
>
> I believe the common implementation for something like
> IEEE_SELECTED_REAL_KIND is to treat it like an ordinary intrinsic
> if there is a visible USE of the module, and the compiler just
> replaces the reference with the result if the actual arguments
> are constants. If they are not constants, then the compiler
> can generate a call to function that has all 64-bit integer
> arguments, including casts to that size as needed for arguments
> that are present. Such “compiler magic” is not directly discussed
> in the standard.
Unfortunately, compiler magic is going to be needed. AFAICT, the
symbol IEEE_SELECTED_REAL_KIND must be in ieee_arithmetic to allow
for renaming via a USE ONLY statement, but the resolution of the
actual interface must occur outside the module due to the ambiguous
interface.
I suppose I find it odd that J3 would define a module procedure
that cannot have its interface expressed in Fortran if a processor
has 2 or more INTEGER kinds.
--
Steve
More information about the J3
mailing list