(j3.2006) ASSOCIATED

[Van Snyder]

Robert Corbett wrote:
> Van's idea of providing two signatures for some intrinsic functions
> provides a way to redefine ASSOCIATED so that it will work, but the
> rewrite required is not small.
>   

1.  It's not my idea, although it is my idea to apply it more broadly.  
It was used in F95, for example for MAXLOC, and might have been used in 
F90 (for which my copy isn't at hand).

2.  All the changes will be in the ALLOCATED subclause, and will consist 
primarily of replacing "present" by "appears".  Perhaps not small, but 
bordering on trivial.  This is the easy problem, however.

3.  The other problem is deeper, much older than "disassociated is 
absent," and much more difficult, because the TARGET argument of 
ASSOCIATED is permitted either to be a pointer, or not a pointer, and if 
a pointer to be associated or not.  Its solution, however, is actually 
cleaner.

The question whether the argument specifications of intrinsic procedures 
apply to actual or dummy arguments appears not to be addressed (if it is 
I can't find it).

ASSOCIATED worked by hand waving until F08, when we added a provision 
that a nonpointer actual argument can correspond to an INTENT(IN) 
pointer dummy argument, in which case the dummy argument becomes pointer 
associated with the actual argument (12.5.2.7p2 in 09-007r3).

Before that, you had to assume the TARGET dumy argument is not a 
pointer, and rely on the exception (12.5.2.3p1 in 09-007r3) that allows 
a disassociated pointer to be an actual argument corresponding to a 
nonpointer dummy argument of an intrinsic function because a pointer 
dummy argument could not correspond to a nonpointer actual argument, but 
then it's hard to imagine how ASSOCIATED could do the job described for 
it.  In any case, you had to wonder "If a nonpointer dummy argument 
becomes associated with the target of a pointer actual argument, what 
does this mean when the pointer is disassociated?"

Without the 12.5.2.3p1 escape clause and the new provision of F08, in 
the case of ASSOCIATED, no matter whether you assume the specifications 
apply to actual or dummy arguments, you encounter contradictions with 
rules for argument association.  For example, starting from the dummy 
argument side, if the TARGET dummy argument is defined not to be a 
pointer, the actual argument has to be either a nonpointer of an 
associated pointer, but the TARGET argument is explicitly allowed not to 
be associated.  If the dummy argument is defined to be a pointer, the 
actual argument has to be a pointer, but it is explicitly allowed not to 
be a pointer.  You eventually arrive at the same contradiction by 
starting with the assumption that the argument specifications apply to 
actual arguments.

The 12.5.2.3p1 escape clause allows the dummy argument not to a 
pointer.  With 12.5.2.7p2, however, it makes more sense to arrive at the 
conclusion that the TARGET dummy argument of ASSOCIATED has to be a 
pointer; we might as well say so.  If we say so, there's no question 
what "optional" and "present"  mean in the face of a disassociated 
actual argument.