[J3] Generic interface for IEEE_SELECTED_REAL_KIND?

[Steidel, Jon L]

There are similar issues with IEEE_REAL and IEEE_INT.  You cannot write a generic interface for them either.
IEEE_REAL has the same interface as REAL, IEEE_INT is similar to INT but with a ROUND argument.  I tripped over
the fact that you could not write an unambiguous interface for these either.

The way around is as Bill mentioned in his first response.  The compiler processes module intrinsics exactly 
like an intrinsic function with a constant argument that can be resolved at compile time to select the correct specific 
function.  The difference between a true intrinsic function and a module intrinsic function the module intrinsic 
function is processed as an intrinsic function only when it is accessible thru the use of an intrinsic 
module.  A flag in the intrinsic table is all that is needed to indicate if these module intrinsics are visible or not within 
the current compilation unit. This flag is set for the module intrinsics in question when the USE statement importing
the intrinsic module is processed. 

-jon

-----Original Message-----
From: J3 [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Steven G. Kargl via J3
Sent: Wednesday, January 2, 2019 8:28 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Steven G. Kargl <kargl at troutmask.apl.washington.edu>; Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] Generic interface for IEEE_SELECTED_REAL_KIND?

On Thu, Jan 03, 2019 at 09:31:32AM +0900, Malcolm Cohen via J3 wrote:
> >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.
> Yes, it is impossible; this is exactly the same as SELECTED_REAL_KIND.
> > Is there a J3 paper that discusses this issue?
> 
> There is no issue.  Like intrinsic procedures, procedures in intrinsic 
> modules are just “magic”, and it’s up to the compiler to work whatever 
> magic is required behind the scenes to make them work.

> A more trivial bit of magic is that references to 
> IEEE_SELECTED_REAL_KIND are permitted in constant expressions, which 
> is impossible for any user module procedure.
> >If the template proposal is accepted then this could be written in 
> >Fortran
> Well, no. That wouldn’t handle passing absent optional arguments to 
> IEEE_SELECTED_REAL_KIND. Again, the compiler magic required to make it 
> work is trivial, viz it is exactly what is already needed for 
> SELECTED_REAL_KIND.

Yes, compiler magic will have to happen.  The magic required for IEEE_SELECTED_REAL_KIND is neither trivial nor exactly like SELECTED_REAL_KIND.  The fact that it can be used in a constant expression is a red herring.  IEEE_SELECTED_REAL_KIND is neither a module procedure as it does satisfy requirements for a module procedure nor is it an intrinsic function.  Given that the precision, range, and radix of real types will likely always fit within the interval [0,huge(0)], J3 could/should have avoided the ambiguity by providing an interface that can actually be written as a module procedure.

--
Steve