(j3.2006) Tobias Burnas question about namelist

[Van Snyder]

Tobias Burnus had a valid quibble with the words about namelist.

At [09-007r3:111:19-20 5.6p5] we find

        A namelist group object shall either be accessed by use or host
        association or shall have its type, type parameters, and shape
        specified by previous specification statements or the procedure
        heading in the same scoping unit or by the implicit typing rules
        in effect for the scoping unit.

The problematic word is "shape," which makes

  real, allocatable :: A(:)
  real, pointer :: B(:)
  namelist /N/ A, B

nonconforming because the shapes of A and B are not specified as
required.

I think this is unfinished business left over from replacing the
constraint at [97-007r2:66:1-4 5.4]:

        A <namelist-group-object> shall not be an array dummy argument
        with nonconstant bound, a variable with nonconstant character
        length, an automatic object, a pointer, a variable of a type
        that has an ultimate component that is a pointer, or an
        allocatable array.

by [04-007:95:10 5.4 C574] which became [09-007r3:111:10 5.6 C585]:

C585 (R564) A <namelist-group-object> shall not be an assumed-size
     array.

Would it be enough to replace "type parameters" by "kind type
parameters" and "shape" by "rank" at [09-007r3:111:19-20 5.6p5]?  Then,
the paragraph could be a constraint.  Surely compilers can handle
forward references by now, so it could be simplified to

C586a (R563) A <namelist-group-object> shall be accessible in the
      scoping unit in which the <namelist-stmt> appears.

Eventually at [09-007r3:223:15-16 9.6.4.7p2] we get around to requiring
that pointer or allocatable namelist group objects have to be associated
or allocated:

        Every allocatable <namelist-group-object> in the namelist group
        shall be allocated and every <namelist-group-object> that is a
        pointer shall be associated with a target.

so they have a shape when the I/O actually takes place.