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

[Bill Long]

On Jan 26, 2016, at 5:14 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

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

OPTIONAL -> PRESENT?

In the ASSOCIATE case, if the selector is OPTIONAL, it has to be present.  So, I don?t see how the associate name gets tainted by optional. 

Cheers,
Bill



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