[J3] Generic interface for IEEE_SELECTED_REAL_KIND?

[Steven G. Kargl]

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