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

[Malcolm Cohen]

Tobias Burnus wrote:
> 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?
What are you talking about?  Implicit typing doesn't depend on invoking 
the function.  In 5.3 IMPLICIT statement it says nothing at all about 
having to invoke a function to get it implicitly typed.

Of course, if not invoked or otherwise used in some way that lets the 
processor know that it's not a subroutine, it is one of those ambiguous 
procedures I mentioned earlier.
>  If
> so, how does an IMPLICIT statement in PROGAM can have an effect if it is
> not typed at all?
>   
Well, in your example the type definition is nested in the same scoping 
unit where it is invoked, but that is hardly likely in real life (unless 
you are one of the few who use SEQUENCE types all over the shop).  The 
implicit type is derived from the implicit mapping *in the type 
definition*; this will typically be the implicit mapping in a module, 
and could well differ from the implicit mapping where it is invoked.

Where is it invoked makes no odds at all.
>
>>>    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
Not in the scoping unit it is not.  This is not a subject for debate.
> ; if not, how do you call it?
Who cares what happens outside the scoping unit?  In your Noddy example 
you have the scoping units nested, but that's not the usual case: it is 
way more common to have types defined in modules.
>  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.
>   
file1.f90:
MODULE m
   IMPLICIT LOGICAL(2)(A-Z)
   TYPE t
     PROCEDURE(),POINTER,NOPASS :: ptr
   END TYPE
END MODULE

file2.f90:
PROGRAM p
   IMPLICIT CHARACTER(37)(A-Z)
   USE m
   TYPE(t) i
   PRINT *,i%ptr()
END

What was that you were saying again?  When the processor is translating 
the type definition it does not have any reference to the component in 
sight.  This is just as true for your example but splitting it into 
separate files on separate machines compiled on separate days makes it 
rather more obvious.

To spell it out: component PTR is ambiguously either a subroutine 
pointer or a LOGICAL(2) function pointer.  It is not a REAL function 
pointer, nor for that matter a CHARACTER(37) function pointer or a 
COMPLEX(2) function pointer!  The words describing the effect of 
implicit typing are not ambiguous here: it is the implicit mapping 
active in the scoping unit of the type definition that matter.
>
> 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.
>   
Well then you would be wrong.  What you do outside a scoping unit does 
not change the meaning of the things defined in the scoping unit.  As I 
said, this is a fundamental principle (which paradoxically is a lot more 
obvious in the general more complicated example than in the 
over-simplified example).

I can understand you thinking otherwise - I did for a while too with the 
original wording in Fortran 90, but a few interp requests later the 
situation became clearer (the committee spelled out more of the edge cases).

I must say this discussion is making me regret we kept so close to the 
dummy procedure analogy (instead of just leaving out the ambiguous 
case).  Can we go back and make them all subroutines instead?  And can I 
have all those hours of my life spent explaining what we were trying to 
do back as well?

Cheers,
-- 
...........................Malcolm Cohen, NAG, Oxford/Tokyo.