(j3.2006) [Re: 8.1.3.2, 8.1.3.3 and 16.5.1.6]

[Van Snyder]

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:
> 
> > 8.1.3.2 and 8.1.3.3 list some of the attributes of an associate name,
> > but don't specify whether the associate name is optional, allocatable or
> > a pointer.  8.1.3.3 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.
> > 
> > 16.5.1.6 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 16.5.1.6 instead of in 8.1.3.3.
> > One might reasonably expect a complete list of the attributes in 8.1.3.2
> > and 8.1.3.3.  Can we move these to 8.1.3.3?
> > 
> > Can we specify in 8.1.3.3 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
> > 7.2.1.2p1(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.
> > 
> > 8.1.3.2p3 belongs in 8.1.3.1, where it would be if it were a constraint.
> > 
> > Similarly, 8.1.9.2p9 belongs in 8.1.9.1, 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
> 
>