(j3.2006) [Re: 126.96.36.199, 188.8.131.52 and 184.108.40.206]
Tue Jan 26 18:14:46 EST 2016
On Jan 26, 2016, at 3:21 PM, Bill Long <longb at cray.com> wrote:
> On Jan 26, 2016, at 4:09 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> > 220.127.116.11 and 18.104.22.168 list some of the attributes of an associate name,
> > but don't specify whether the associate name is optional, allocatable or
> > a pointer. 22.214.171.124 says that if the selector is optional it shall be
> > present, but doesn't way whether the associate name has the OPTIONAL
> How could a construct entity like an associate name be a dummy
> argument (which is a requirement for having the OPTIONAL attribute)?
It's not obvious that a construct entity associated with a dummy
argument is not a dummy argument. After all, a host associated dummy
argument is, apparently, enough of a dummy argument that it can appear
as the argument to the OPTIONAL intrinsic function.
We finesse the question of INTENT(IN) for associate names by saying that
if the selector cannot appear in a variable definition context, then
neither can the associate name.
> > attribute. This affects whether a reference to the PRESENT intrinsic
> > function can appear with an associate name as an argument.
> > 126.96.36.199 says the associate name is not allocatable and not a pointer.
> > It's not helpful not to have the specification that the associate name
> > is not allocatable and not a pointer in 188.8.131.52 instead of in 184.108.40.206.
> > One might reasonably expect a complete list of the attributes in 220.127.116.11
> > and 18.104.22.168. Can we move these to 22.214.171.124?
> > Can we specify in 126.96.36.199 whether the associate name is optional? I
> > assume we want the answer to be "no," but we should say so. Otherwise,
> > one doesn't know whether a reference to the OPTIONAL intrinsic function
> > can appear.
> > Further, it's not helpful that the associate name is polymorphic but not
> > allocatable, as this prohibits intrinsic assignment to it -- see
> > 188.8.131.52p1(1). One cannot easily make it nonpolymorphic with a type the
> > same as its declared type using a SELECT TYPE construct. One needs a
> > SELECT TYPE construct with a TYPE IS block and a CLASS DEFAULT block,
> > the first doing what one wants done to the object, and the second doing
> > exactly the same thing to the ancestor component of the object.
> > Otherwise, one needs to operate on the ancestor type's components
> > individually.
> > In addition to a parent component, a type needs a nonpolymorphic self
> > component of the same type, type parameters, and name as itself.
> > 184.108.40.206p3 belongs in 220.127.116.11, where it would be if it were a constraint.
> > Similarly, 18.104.22.168p9 belongs in 22.214.171.124, where it would be if it were a
> > constraint.
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.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
More information about the J3