(j3.2006) 240 is wrong

[Van Snyder]

On Fri, 2014-10-03 at 21:06 +0000, Bill Long wrote:
> 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.

V%C is not a name, and therefore, according to 6.3p1, V%C is not a named
variable.  5.3.13 doesn't specify that it has the PARAMETER attribute.

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

Both of those are literal constants; neither one is a subobject.

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

And according to definitions in 2.4.3.2.3p1 and 6.3p1 it's also not a
constant.  It is a constant expression according to 7.1.12.

I'm not arguing against what we all believe these things ought to be,
just describing what the standard fails to say.

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