Re: Procedure Pointer (Components) with no explicit interface and with implicit typing

Hello all,

I am *partially* answering myself below - but I am not completely sure
regarding some parts -- see especially at the bottom.

Tobias Burnus wrote:
The question is now: If I have a procedure pointer,
PROCEDURE(), POINTER :: procptr
in principle, I can assign to it either a function nor a subroutine, e.g.
procptr => sub
call procptr() ! (C)
procptr => func
x = procptr() ! (D)
Thus the function call (D) and the subroutine call (C) are both well
defined (whether they are valid standard Fortran is a different question).

Am I understanding the standard correctly, that (D) is invalid because
"procptr" has been used as subroutine before?


I am reading the following such that the last two lines of the code
snippet above are invalid because of the following:

"7.4.2.2 Procedure pointer assignment"
"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."


Analogously, one can have

type t
procedure(), pointer, nopass :: p
end type t
type(t) :: a, b
external :: func, sub

a%p => sub
b%p => func
call a%p
y = b%p()

(I believe the program above is valid)

Is it correct according to the standard that now "a%p" can not be used
as a function and b%p not used as subroutine since there was "call a%p"
and "y = b%p" before?

I think the same clause as above applies here, which makes any of the
following invalid if *added after* the code above:
"a%p=> func", "y = b%p()", "b%p => sub" and "call b%p".


Additionally, is it correct that "b%p" gets implicitly typed as REAL in
this example?

I believe it does get implicitly typed as in
b % p
"p" is the data entity / name which is referred to in "5.3 IMPLICIT
statement":

"Any data entity that is not explicitly declared by a type declaration
statement, is not an intrinsic function, and is not made accessible by
use association or host association is declared implicitly to be of the
type (and type parameters) mapped from the first letter of its name,
provided the mapping is not null."

Thus in "y = b % p()", "p" is implicitly typed as REAL (assuming no
IMPLICIT statement is present).


And thus, if there were an "IMPLICIT NONE", I could not
call it as function

This is still unclear to me.

F2003 has in 7.4.2.2:
"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."
"If proc-target and proc-pointer-object are functions, they shall have
the same type; corresponding type parameters shall either both be
deferred or both have the same value."

Assuming:
IMPLICIT NONE
real, external :: func
procedure(), pointer :: p
p => func
and furthermore assuming that p is not referenced as function (nor as
subroutine).

I don't see why it is invalid. But if it where valid, the following were
valid as well:

implicit none
external :: func
procedure(), pointer :: p1
procedure(REAL), pointer :: p2
real :: y
p1 => func ! (A)
p2 => p1 ! (B)
y = p2()

(A) is the questionable part from above. For (B) one has: p2 is
explicitly typed as function thus p2 needs to be associated with a
function with the same type. If it were associated if p1, it were
invalid as p1 does not have the right type (zero implicit mapping);
however, p2 is associated with the target of p1 (*) which is "func"
which is a real function.
(* = "if proc-target is associated with a procedure, proc-pointer-object
becomes associated with the same procedure.")

The three compilers I tried, accept (A) but reject (B).

Tobias
.

Relevant Pages