[J3] Generic interface for IEEE_SELECTED_REAL_KIND?

[Rafik Zurob]

> 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

In XLF, we started out with making the compiler check that the intrinsic 
module (with the expected name) was used before enabling the intrinsic. 
While it's good for valid programs, it didn't catch all invalid programs. 
It also got tedious when we started supporting many more intrinsic modules 
for CUDA Fortran.  So I came up with the following pattern:

module ieee_arithmetic_impl
  implicit none

  intrinsic __ieee_selected_real_kind
end module

module ieee_arithmetic
  use, intrinsic :: ieee_arithmetic_impl, &
    only: ieee_selected_real_kind  => __ieee_selected_real_kind
end module

The above assumes that the compiler intrinsic that implements 
ieee_selected_real_kind is called __ieee_selected_real_kind.  You need a 
name that's reserved for your compiler's use.  You then ship 
ieee_arithmetic.mod but not ieee_arithmetic_impl.mod.  That way, users 
won't get access to the "ieee_selected_real_kind" name unless they use the 
ieee_arithmetic module.  And users using ieee_arithmetic in their own 
modules are free to rename ieee_selected_real_kind and control its 
accessibility in their modules as they please.

Regards

Rafik