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

[Robert Corbett]

Van Snyder wrote:
> 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 the problem is more than just the issue of determining rank.
Consider the example I gave in my second e-mail on the subject.
There, the result is determined to be scalar regardless of whether
the pointer is associated or not.

The problem goes beyond the optional DIM dummy arguments.  As I noted
in my second e-mail, we need to decide whether or not "absent" means
the same thing as "not present," and whatever we decide needs to be
applied consistently in the specifications of the intrinsic functions.
I shall suggest that if we decide "absent" maens "not present," we
say "not present" instead of "absent."

> 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.

I started writing one two days ago.  Perhaps we should compare notes.

> -------- 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
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3