[J3] Generic interface for IEEE_SELECTED_REAL_KIND?

[Steven G. Kargl]

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