(j3.2006) 240 is wrong

[Bill Long]

On Oct 3, 2014, at 3:35 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> On Fri, 2014-10-03 at 15:02 +0900, Malcolm Cohen wrote:
>> 2 v%c is not a variable
>> 3 v%c is not a variable
>> 4 v%c is not a variable

Clearly. 

> 
> They aren't variables under the definition in 1.3.156, but it's not
> obvious they're constants.  They're definitely not literal constants.
> According to 6.3, "A constant is a named constant or a literal
> constant....  A named constant is a constant that has a name; the name
> has the PARAMETER attribute."  v%c is not a name; it's a designator.

V is a name. 

> Unlike the case for the INTENT attribute (5.3.10p6), 5.3.13 doesn't say
> that subobjects of an object with the PARAMETER attribute have the
> attribute.  6.3p1 doesn't say that a subobject of a constant is a

So, you?re saying that if I consider the constant ?Van_Snyder?, then the subobject ?Van? is somehow NOT a constant?  Or if I declare

character(*),parameter :: C = ?Van_Snyder"

then C(1:3)  qualifies at least as a constant expression.  Certainly that precludes it from being a variable.

Cheers,
Bill


> constant.  2.4.3.2.3p1 says a subobject of a constant is a portion of a
> constant, but doesn't say that it IS a constant.  7.1.12p1(1) says "a
> constant or a subobject of a constant."  The phrase "or subobject of a
> constant" wouldn't be necessary if we said that in 2.4.3.2.3p1 or 6.3p1.
> 
> Perhaps we need to say in 6.3p1 that "A named constant has a designator
> for which the first <part-name> has the PARAMETER attribute."  We don't
> need to say "A named constant is a constant that has a..." because of
> the first sentence of 6.3p1. We don't want to say that the designator is
> a constant expression, because then things like A(I), where A is a
> parameter and I is a variable, would not be constants -- there is a
> difference between constants and constant expressions.  2.4.3.2.3p2
> clearly contemplates this.  Then in 5.3.13 add "A subobject of an object
> with the PARAMETER attribute has the PARAMETER attribute." (Compare to
> 5.3.10p6.)
> 
> There might be holes where we say "constant" instead of "constant
> expression."  Better to define "constant" correctly and completely
> instead of waving our hands and hoping we find all the holes.
> 
>> The flaw in ASSOCIATE is that the "associate-name" should have been 
>> "associate-name or subobject thereof".  SELECT TYPE is peculiar in that here it 
>> is a constraint, but has the same flaw (unsurprisingly).
>> 
>> All the references to variable definition context bar those two seem perfectly 
>> fine.
> 
>> Obviously there is a different fix for this, and there is no incompatibility 
>> since no interpretation was established for the broken usage.
> 
> Which repair is preferred?  Add "or a subobject thereof" in (13) or add
> 
> "(13a) a subobject of the variable appears in a variable definition
>       context;"
> 
> 14-136r1 proposed the "or a subobject thereof" fix in 16.6.7p1(13).  It
> doesn't hurt to add the (13a) list item suggested in 14-240, and it
> definitely covers more ground.  It might cover obscure cases such as the
> failure to specify that a subobject of a constant is a constant, or that
> a subobject of a parameter has the PARAMETER attribute.
> 
> It might be desirable to replace the first sentence of 8.1.3.3p2 with
> "The associating entity is a variable if and only if the selector is a
> variable" to avoid the appearance of a conflict with 1.3.156, or the
> need of a caveat to avoid it.  This wouldn't be enough to solve the
> entire problem, because the second sentence is still necessary, for
> example if the selector has the INTENT(IN) attribute, because 8.1.3.2
> doesn't say that the associate name has the same INTENT attribute as the
> selector if the selector has an INTENT attribute.
> 
> During development of the ASSOCIATE construct I preferred to add "the
> associate name has the same attributes as the selector," but that would
> have made the associate name allocatable or a pointer if the selector
> was, and we decided not to do that to maintain the parallel to argument
> association.
> 
> 
> _______________________________________________
> 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 Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101