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

[Bill Long]

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 this is what Bob was getting at, without say saying as much, in
> his message that started this discussion.

I think you are saying (perhaps more clearly) the same thing that I 
replied originally:

The goal here is to ensure that the compiler can tell at compile time
whether the result is a scalar or an array, based on whether or not DIM
is "absent".  The standard is clear that the rules regarding optional
arguments are the ones specified in 12.5.2 (see 09-007r3[317:33-34]).
The restriction that the actual DIM argument cannot be an optional dummy
is to circumvent a possible ambiguity.  I think we should have also
disallow unallocated allocatable variables and pointers that are not
associated as actual arguments.  Seems like interp material.

> 
> I'll write an interp paper.

Thanks.  This seems like a missed "integration" issue.

Cheers,
Bill

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

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101