[J3] Generic interface for IEEE_SELECTED_REAL_KIND?

[Bill Long]

> On Jan 2, 2019, at 3:34 PM, Steven G. Kargl <kargl at troutmask.apl.washington.edu> wrote:
> 
> 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.

Ah, right.  The OPTIONAL arguments are the problem. 

> 
>> 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. 


If the template proposal is accepted then this could be written in Fortran.  In the simple (and common) case that the processor’s normal real KINDS are all IEEE kinds, in the ieee_arithmetic module you would have just (modulo making final decisions about template syntax)

template function ieee_selected_real_kind (p, r, radix)  result (res)

   integer :: res
   integer(*),optional :: p, r, radix

   res = selected_real_kind (p,r,radix)

end function ieee_selected_real_kind

and rely on the fact that the (non-module) intrinsic selected_real_kind already uses the “compiler magic”.  In this example, any supported integer kind for the arguments to ieee_selected_real_kind in the caller would be accepted. 


> 
> 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.

I appreciate the frustration in this case.  I believe the goal here was to have consistent interfaces for selected_real_kind and ieee_selected_real_kind.  But there is the awkward side effect you point out.  The typical user does not try to write the ieee_arithmetic module source code, so the current specification is the better option for most programmers.  The burden is on the compiler vendors to “make it work”. 

Cheers,
Bill


> 
> -- 
> Steve

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425