(j3.2006) [Third thoughts about DIM arguments]

[Van Snyder]

Upon further reflection I think we do need an interp concerning
disassociated pointers or deallocated allocatables corresponding to DIM
arguments of several intrinsic functions.

The DIM arguments are described as being optional.  There is a
prohibition against the associated actual argument being an optional
dummy argument.  The intent is that the processor can determine the rank
of the result, which is described using the term "present" in the Result
Characteristics paragraph.

We added a provision that a disassociated pointer or deallocated
allocatable that appears as an actual argument associated with an
optional dummy argument results in the dummy argument being considered
not to be present.

Thus with the present description, the processor can't determine the
rank until the program executes.

I think this is what Bob was getting at, without say saying as much, in
his message that started this discussion.

I'll write an interp paper.

-------- Forwarded Message --------
From: Van Snyder <Van.Snyder at jpl.nasa.gov>
Reply-To: Snyder, W Van (3284) <W.Van.Snyder at jpl.nasa.gov>, fortran
standards email list for J3 <j3 at j3-fortran.org>
To: j3 <j3 at j3-fortran.org>
Subject: (j3.2006) Second thoughts about DIM arguments
Date: Wed, 10 Mar 2010 14:01:13 -0800

Yesterday I offered an opinion about how the optional DIM argument ought
to be described for those intrinsic functions where its presence
determines the rank of the result.  I suggested that some of them could
be described either as optional arguments or by showing two interfaces,
one with DIM and one without.  Some with more than one optional argument
can't be described using two interfaces without introducing technical
changes.

Anyway, it's pretty clear that the rank of the result can be determined,
even if the DIM argument is a disassociated pointer or unallocated
allocatable.  In those cases, however, the invocation can't be executed
-- but that's a different question from what the rank of the result is.

So, I don't think we need any interps.  I don't think we need to change
any description from "absent" to "does not appear," although that
wouldn't hurt anything since the actual argument is not allowed to be an
optional dummy argument.  The advantage of changing it is that we could
remove the prohibitions against optional dummy arguments, since that's
covered elsewhere (an absent optional dummy can't correspond as an
actual argument to a nonoptional dummy).

It would be helpful to describe CSHIFT and EOSHIFT using "absent"
instead of "omitted" (or "does not appear" if we choose to go in that
direction).  These are the only two places where "omitted" appears in
Clause 13.

====================================================================
ANY can go either way.
COUNT has to be described using "does not appear".
CSHIFT doesn't use DIM to determine the rank, but uses "omitted" and
"present" instead of "absent" and "present".
Same for EOSHIFT.
FINDLOC is already described using two interfaces.
IALL is already described using two interfaces.
IANY is already described using two interfaces.
IPARITY is already described using two interfaces.
LBOUND has to be described using "does not appear".
LCOBOUND has to be described using "does not appear".
MAXLOC is already described using two interfaces.
MAXVAL is already described using two interfaces.
MINLOC is already described using two interfaces.
MINVAL is already described using two interfaces.
NORM2 can go either way.
PARITY can go either way.
PRODUCT is already described using two interfaces.
SUM is already described using two interfaces.
UBOUND has to be described using "does not appear".
UCOBOUND has to be described using "does not appear".
====================================================================


_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3