J3/01-281

Date:     August 4, 2001
To:       J3
From:     Dick Hendrickson
Subject:  Chapter 5 comments

1)  Page 63, Ch 5 1st paragraph, last line.  There is no CLASS
statement.  After "attributes" add ", except CLASS," on next to last
line.

2)  Page 63, C503.  Shouldn't there also be a constraint, similar to
C501, that says the type-alias shall only have : or * pr spec-exprs in
it?  Or does that follow from the recursive definition of type-alias
R452 into declaration-type-spec

3)  Page 84, C504.  I think the only place a type-parem-value can appear
is in the char-length.  If that's true, we should use char-length in the
constraint.

4)  Page 64, R506.  This is one of the default rules.  C505 could easily
apply to R505.

5)  Page 64, C522.  I don't understand the use of "variable" for
allocatable things.  Everything else is an "object"

6)  Page 65, C529.  Should we also disallow INTENT(OUT) for language
binding things?  INTENT(OUT) implies initialization of the variable and
I don't think the C processor will do the right thing.

7)  Page 68, I don't understand (3)

8)  Page 68, 5.1.1.8, 3rd paragraph, first line.  Is it also type
compatible with a type that extends another but is itself not
extensible?  The second line talks about "the same type or any of its
extension types" which makes me think the first line is limited.  Does
EXTENDS imply EXTENSIBLE?  I didn't think so.

9)  Page 68, 5.1.1.8, last line, add "of any type" after "objects" to
make it parallel with first part of paragraph.  Otherwise the sentence
applies to all things.

10)  Page 70, C542 and C543.  Is there a reason why the second is less
restrictive than the first constraint?

11)  Page 71, third paragraph after R520.  Should add "or when argument
associated" at end.
Does this also apply to allocatable components TR?

12)  Page 71, paragraph before R520 and bullets (1) and (2) after R520.
I think pointer array bounds are also determined by argument
association.  Ch 5 also applies to dummy arguments which can have their
attributes set before a subprogram is invoked.  True, the dimensions are
set in the way described.  But those are the dimensions of the actual
argument.  They don't become the dimensions of the dummy until argument
association takes place.

13)  Page 73, 5.1.2.5, last paragraph.  It looks like some, but not all,
of interp 70 from corrigendum 1 have been applied here.  Is it true that
in general the corrigendum haven't been applied yet?

14)  Page 76, 5.1.2.12, second paragraph.  Don't we need a similar
paragraph for COMMON

15)  Page 77, Note 5.21.  I don't understand this note.  I agree with
the last sentence, I just don't understand the reasoning.

16)  Page 77, 5.1.2.14   I think 12.4.1.2 is a better reference

17)  Page 77, 5.2, first line.  "other than type" => "other than type or
class"?

18)  Page 82, 5.2.11  R549  Is this rule needed?  It's covered by the
general chapter 1 rules.

19)  Page 83, R554.  Do we need a constraint saying this can't be a
CLASS?  If so, we should do a grep for all occurrences of
[declaration-]type-spec and check them also.

20)  Page 84, 3rd paragraph after C576, first sentence.  Do we need to
add import to this list?

21)  Page 86, C577.  Can it be an imported name?  Page 241 says an
imported name can't appear in any statement that would specify any
attribute.  Does namelisting specify an attribute?  In common English it
does, but does it do it here?  Attribute is a property that may be
specified in a type decl statement.  Do we need to grep for association
and see if IMPORT needs to be added or prohibited?

22)  Page 86, last paragraph.  May it appear more than once in the same
statement?
    NAMELIST   /LIST/ A,B    /LIST/ C

23)  Page 87, 3rd line.  How can a namelist object have its type defined
by the procedure heading?  The namelist object must be a variable and
that doesn't include function names.

24)  Page 90, C593.  Can a common block variable be import or host
associated?