[J3] Is this standard-conforming?

[Van Snyder]

On Thu, 2018-07-26 at 18:38 +0000, Bill Long via J3 wrote:
> Thanks, Dan, for looking this up. At least by m218 the /INTERP
> subgroup should be back in business.  
> 
> I should note that there IS a way around this for a function type.
> Instead of 
> 
>     type(ugg) function foo()
> 
> you can write
> 
>     function foo()  result(res)
>       import ugg
>       type(ugg) :: res
> 
> In the second case there is no room for ambiguity because the use of
> ugg is in the specification part of the function which is clearly
> covered by the import statement.  However, the standard still permits
> the first version, hence the need for compilers to implement a limited
> look-ahead capability. 

7.3.2.2p2 (in N2155) says "If the data entity is a function result, the
derived type may be specified in the FUNCTION
statement provided the derived type is defined within the body of the
function or is accessible there by use or
host association.  If the derived type is specified in the FUNCTION
statement and is defined within the body of the function, it is as if
the function result were declared with that derived type immediately
following the derived-type-def of the specified derived type."

But I couldn't find anything similar about BIND, about the effect of a
type being accessed by use association being as if the result variable
were declared immediately after the USE statement, or about type
parameters of intrinsic types.

I don't think any processor would complain about

  real(rk) function F ( X )
    use MyKinds, only: RK
    ...

but I can't find anything that requires them to accept it.  Doesn't mean
it's not there, just that I can't find it.

> 
> 
> Cheers,
> Bill
> 
> 
> > On Jul 26, 2018, at 1:12 PM, Dan Nagle via J3 <j3 at mailman.j3-fortran.org> wrote:
> > 
> > Hi,
> > 
> >> On Jul 26, 2018, at 10:23 , Bill Long via J3 <j3 at mailman.j3-fortran.org> wrote:
> >> 
> >> Similar to your case, the import of ugg  from the host occurs on the statement after the one where ugg is used.  In the case of a type definition like this there is no practical alternative, so compilers have been taught to ‘look ahead’ for a type definition.   I suspect we intended to allow the case you described, but the vendors did not anticipate needing to do a look-ahead for anything other that the function type.   If Malcolm disagrees about the intent, I’m ok with that.   I think it boils down to whether the FUNCTION statement itself is part of the scoping unit of the function. 
> >> 
> > 
> > And indeed, this is the oldest interpretation request in the file.
> > The issue has been argued, and the argument accepted, both ways.
> > 
> > --
> > 
> > Cheers!
> > Dan Nagle
> > 
> > 
> 
> 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
> 
>