(j3.2006) Procedure(), pointer: subroutine vs. function and implicit typing
Thu May 14 15:28:28 EDT 2009
Malcolm Cohen 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.
You mean that for
y = i%ptr()
i%ptr has to point to a real function but never gets typed at all since
in TYPE it cannot be typed and in PROGRAM it is too late to be typed? If
so, how does an IMPLICIT statement in PROGAM can have an effect if it is
not typed at all?
>> procedure(), pointer :: ptr
> You probably want NOPASS on this as well,
Yes, I forgot that one.
>> type(t) :: i
>> i%ptr => proc
>> y = i%ptr()
> 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.
I see some difference here: It might be like a dummy procedure, but I
would call "y = i%ptr" as referenced; if not, how do you call it? I also
expect as reader that
print *, i%ptr() or y = i%ptr()
tells the compiler that i%ptr() can be regarded as function, seemingly
as real function.
I see the relation to:
y = p()
I agree that "call sub(proc)" does not change the type of "proc" in the
host scope, but I'd claim that "y = p()" causes "p" to be referenced and
typed as REAL.
>> b) The example Richard mentioned - is the following valid?
>> procedure(),pointer :: proc_pointer
>> if (do_the_subroutine) then
>> proc_pointer => some_subroutine
>> call proc_pointer(5)
>> proc_pointer => some_function
>> y = proc_pointer(7)
>> end if
> 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.
That was my reading though I was unsure; the pointer targets are
properly used and it could be allowed by standard (in theory). But as it
isn't it makes live easier for the compiler writer (and less flexible
but less flexible for the programmer).
>> 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
> 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
I am (or at least was) a bit unsure about this one as "func" is not
referenced as function, unless "p => func" counts as such. And if it is
not referenced, it will not be typed and thus the null mapping due to
the IMPLICIT NONE does not matter. But I probably think too much around
corners. At least I'm very happy to accept that it is invalid as it
makes live much easier, e.g. by disallowing the other example.
> No money-back guarantee if I've made a mistake in my answers.
Well, you have time to think about it a bit more as I submitted an
official interpretation request (with the PASS fixed).
More information about the J3