(j3.2006) 240 is wrong

[Malcolm Cohen]

>>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
>
>They aren't variables under the definition in 1.3.156, but it's not
>obvious they're constants.

So what?  They are not cups of coffee either.  That does not mean that they 
are variables!

Really this is ancient known stuff, there are variables, there are 
constants, there are constant expressions, and there are subobjects of 
constants.  Only the variables are variables.  None of the others are 
variables.

For a trivial example of a subobject of a constant that is not a constant, 
consider
  INTEGER,PARAMETER :: X(3) = [ 1,2,3 ]
  ...
  DO i=1,3; PRINT *,X(i); END DO

Rather obviously, X(i) is not a variable, a constant, or a constant 
expression.  It is a subobject of a constant though.

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

Good.

>  6.3p1 doesn't say that a subobject of a constant is a
>constant.

Good.

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

Good.

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

Wrong.

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

NNNNNOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

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

We are not waving our hands.

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

No.  Fix the flaws in ASSOCIATE and SELECT TYPE.  Other places are careful 
to include subobjects when that is desired.

Cheers,
-- 
...............................Malcolm in a typhoon.