12-157
To: J3
From: Malcolm Cohen
Subject: Interp NAMELIST and shape specification
Date: 2012 June 15

----------------------------------------------------------------------

NUMBER: F08/0079
TITLE: NAMELIST and shape specification
KEYWORDS: NAMELIST
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Q1.  Consider

  Program m198_002a
    Real,Allocatable :: x(:)
    Namelist/n/x
    x = [ 1,2,3 ]
    Write (*,n)
  End Program

The standard requires, at 5.6p5,
   "A namelist group object ... shall have its ... shape specified
    by previous specification statements ...".

The shape of X is specified by the assignment statement, this is
neither previous nor a specification statement, so apparently this
does not conform to the standard.  However, the paper that removed the
previous constraint against ALLOCATABLE in NAMELIST, 01-125r1, seems
to indicate that it was intended to allow ALLOCATABLE in NAMELIST, not
merely to make it difficult to understand the standard.

Is this program intended to be standard-conforming?

Q2.  Consider

  Program m198_002b
    Call test(3)
  Contains
    Subroutine test(n)
      Call sub([(i,i=1,n**2)]) ! B
    End Subroutine
    Subroutine sub(y)
      Integer,Intent(In) :: y(:) ! A
      Namelist/n2/y
      Write (*,n2)
    End Subroutine
  End Program

The shape of Y is specified at "! A" to be assumed from the actual
argument, and in this case that means that the actual shape is
specified by the array constructor at "! B".  The text quoted from the
standard in Q1 says that the "shape [shall be] specified by [a]
previous specification statement", but the actual shape is not so
specified.

Is this program intended to be standard-conforming?

Q3.  Consider the same example as in Q2, but with the INTEGER and
     NAMELIST statements swapped.  This clearly violates the
     requirement quoted from the standard, but if prior specification
     is not going to be required for ALLOCATABLE (which if ALLOCATABLE
     is going to be allowed, must inevitably be the case), it does not
     seem to make sense to require it for other cases.

Is this modified program intended to be standard-conforming?


ANSWER:

A1.  This program was intended to be conforming.

A2.  This program was intended to be conforming.

A3.  This program was intended to be conforming.

An edit is supplied to remove the defective requirement.


EDITS:

[111:19-20] In 5.6 paragraph 5,
  Change "type, type parameters, and shape"
  to "type and type parameters".

SUBMITTED BY: Malcolm Cohen

HISTORY: 12-nnn    m198  F03/0079 submitted

----------------------------------------------------------------------