(j3.2006) 8.1.3.2, 8.1.3.3 and 16.5.1.6

[Bill Long]

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


> 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