(j3.2006) Procedure(), pointer: subroutine vs. function and implicit typing

[Malcolm Cohen]

Tobias Burnus wrote:
>
> a) Implicit typing. Am I reading the standard correctly that for the
> following example, "i%ptr" gets implicitly typed as REAL?
>   
No, that's not right.  Within the scoping unit, "ptr" is not referenced 
in any way.  The scoping unit being the type definition.

It is a basic principle that once you reach the end of a scoping unit, 
any subsequent inner/outer statements cannot go back and retrospectively 
change the meaning of the things defined by that scoping unit.  This 
applies to modules and host scoping, as well as type definitions.
>    procedure() :: proc
>    type t
>       procedure(), pointer :: ptr
>   
You probably want NOPASS on this as well, otherwise an intelligent 
compiler might work out that there are no procedures that can match this 
pointer and reject the whole thing.
>    end type t
>    type(t) :: i
>    i%ptr => proc
>    y = i%ptr()
>    end
>
>   
I think the type definition means that PTR is an ambiguous procedure 
pointer - it can point to either a real function or a subroutine.  Just 
like a dummy procedure that's not referenced within a subprogram.

We deliberately decided to make procedure pointers as much like dummy 
procedures as we could, including the slightly weird ambiguous case.  
The ambiguous case is fine (IMO) for normal procedure pointers, but 
rather icky for procedure pointer components.
>
> b) The example Richard mentioned - is the following valid?
>
>   external some_subroutine, some_function
>   procedure(),pointer :: proc_pointer
>   logical :: do_the_subroutine
>   if (do_the_subroutine) then
>      proc_pointer => some_subroutine
>      call proc_pointer(5)
>   else
>     proc_pointer => some_function
>     y = proc_pointer(7)
>   end if
>   end
>
>
> And without the "if"s? In the standard (7.4.2.2) one finds the following
> but it is not completely clear to me whether it applies:
>
> "If proc-pointer-object has an implicit interface and is explicitly
> typed or referenced as a function, proc-target shall be a function. If
> proc-pointer-object has an implicit interface and is referenced as a
> subroutine, proc-target shall be a subroutine."
>   
Why would this not apply?

It makes your example invalid - PROC_POINTER is referenced as a function 
and as a subroutine, which means that <proc-target> must be a function 
and be a subroutine, clearly impossible to satisfy.
> For the if-free version, I'm inclined to say that 7.4.2.2 applies and
> that it would be invalid - but for the if-version?
>   
I don't see how the presence of an IF construct can possibly be 
construed as changing anything here (or, in general, in any case 
whatsoever).

Like the ambiguous dummy procedure situation, it's only ambiguous (viz 
accepting both of subroutines and one kind of function) when there is no 
reference in the scoping unit.  That's not the case here, instead we 
have conflicting references.
>
>
> c) Is the following valid?
>
> IMPLICIT NONE ! p is not implicitly typeable
> real, external :: func
> procedure(), pointer :: p
> p => func
> ! However, p is not referred as function
> end
>   
Obviously cannot be valid, since for P to be an implicitly typed 
function pointer would violate IMPLICIT NONE.  So P is a subroutine 
pointer, and you are not permitted to assign a function to a subroutine 
pointer.
> And related - especially if (c) is valid:
>
>
>
> d) Is the following valid?
>
> implicit none
> real, external :: func
> procedure(), pointer :: p1 ! not implicitly typeable
> procedure(REAL), pointer :: p2
> real :: y
> p1 => func ! (A)
> p2 => p1 ! (B) Assign target of p1 (i.e. "func") to p2
> y = p2()
> end
>   
Obviously cannot be valid for similar reasons.

No money-back guarantee if I've made a mistake in my answers.

Cheers,
-- 
.......................Malcolm Cohen, Nihon NAG, Tokyo.