From jwagener@trc.amoco.com Wed Dec  9 08:05:05 1992
Received: from noc.msc.edu by dkuug.dk with SMTP id AA22271
  (5.65c8/IDA-1.4.4j for <SC22WG5@dkuug.dk>); Wed, 9 Dec 1992 21:05:33 +0100
Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
	id AA04067; Wed, 9 Dec 92 14:05:30 -0600
Received: from [149.180.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212))
	id AA16181; Wed, 9 Dec 92 14:05:23 -0600
Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0)
	id AA28504; Wed, 9 Dec 92 14:05:15 CST
Received: from crmac1 by trc.amoco.com (4.1/SMI-4.1)
	id AA18430; Wed, 9 Dec 92 14:05:05 CST
Date: Wed, 9 Dec 92 14:05:05 CST
Message-Id: <9212092005.AA18430@trc.amoco.com>
From: Jerrold L. Wagener <jwagener@trc.amoco.com>
To: SC22WG5@dkuug.dk
Subject: S20.123, items 61-90
X-Charset: ASCII
X-Char-Esc: 29


NUMBER: 000061
TITLE: G edit descriptor with "d" = 0
KEYWORDS: G edit descriptor
DEFECT TYPE: Erratum
STATUS: X3J3 approved; ready for WG5

QUESTION: Is a value of 0 for "d" in a G edit descriptor (e.g. 1PG8.0)
permitted?

ANSWER: Yes. See R1008, R1005, and R404.

QUESTION: Did the committee mean to change the definition of G format in
Fortran 90 (compared to FORTRAN 77)?

ANSWER: Yes. The form of output text produced by the G edit descriptor for
some values and particular edit descriptors was intentionally changed. The
changes require processors to give meaningful output instead of "*"s for
certain values and edit descriptors.

QUESTION: What happens when N (the value to be printed) is zero and "d" is
zero?

ANSWER: The standard indicates a format of F(w-n).-1 is to be used. This
is an error in the standard.

REFERENCES: ISO/IEC 1539:1991 (E) Rules R404, R1005, and R1008

EDIT(S):

   1. In section 10.5.4.1.2 second paragraph, 3rd sentence, after
      "-0.5," add " or N is identically 0 and d is 0,".

   2. In section 10.5.4.1.2, second paragraph, fourth sentence, after "N
      is identically 0" add " and d is not zero".

   3. In section 1.4.1, add item (5) as follows:

     (5) A value of 0 for a list item in a formatted output statement will
         be formatted in a different form for some G edit descriptors. In
         addition, the Fortran 90 standard specifies how rounding of
         values will affect the output field form, but FORTRAN 77 did not
         address this issue: therefore, some FORTRAN 77 processors may
         produce a different output form than Fortran 90 processors for
         certain combinations of values and G edit descriptors.

SUBMITTED BY: J.Brixius, 121-JB-1

HISTORY: 121-ADT-7 pp 1-9, 92-076, 92-118
         Approved as X3J3/92-149A at meeting 122 by a vote of 20-3
         Edit approved in 92-267r at meeting 123

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

NUMBER: 000062
TITLE: Statement function constraints
KEYWORDS: statement function, host association
DEFECT TYPE: Erratum
STATUS: X3J3 approved; ready for WG5

QUESTION: Does the last constraint under R1226 allow variables in a
<scalar-expr> of a statement function definition to be accessed via host
association or use association?

          PROGRAM HOST
            INTEGER I
            ...
            CONTAINS
              SUBROUTINE INNER()
                STMTFUNC()=I+1
                ...

ANSWER: Yes.

Discussion: It was the intent of the committee to allow variables made
accessible by use or host association to appear in a <scalar-expr> of a
statement function definition. The text of the last constraint under R1226
needs clarification to better reflect that intent.

REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.4

EDIT(S): In the last constraint after R1226 in section 12.5.4 replace
"local to" with "accessible in".

SUBMITTED BY: J.C.Shepherd X3J3/92-015

HISTORY: Discussed in X3J3/92-046 pp 28-29
         Initially drafted as X3J3/92-120
         Approved as X3J3/92-160 at meeting 122 by a vote of 23-0
         Approved in ballot 92-182

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

NUMBER: 000063
TITLE: Interfaces and dummy procedure arguments
KEYWORDS: interface, dummy procedure
DEFECT TYPE: Interpretation
STATUS: X3J3 approved; ready for WG5

QUESTION: Given a procedure that has a dummy argument, must an explicit
interface for the procedure show sufficient information to indicate that
its dummy argument is a dummy procedure?

ANSWER: Yes.

Discussion: The first sentence of the second paragraph in 12.3.2.1
indicates that an interface body must specify all of the procedures
characteristics. Section 12.2 indicates that a procedure's characteristics
include the characteristics of its arguments. Therefore, an interface body
must include an EXTERNAL statement or a nested interface block for each
dummy argument that is a dummy procedure, even though this may not be
necessary in the procedure definition.

REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.2 and 12.3.2.1

EDIT(S): None.

SUBMITTED BY: J.C.Shepherd, X3J3/92-016

HISTORY: Approved as X3J3/92-161 at meeting 122 by a vote of 24-0
                   Approved in ballot 92-182

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

NUMBER: 000064
TITLE: SPACING result for 0.0
KEYWORDS: SPACING intrinsic
DEFECT TYPE: Erratum
STATUS: X3J3 approved; ready for WG5

QUESTION: Is the SPACING intrinsic function intended to return absolute
spacing of model numbers about 0.0 when its argument is 0.0?

Section 13.12.100 under Result Value specifies that the result should be
b**(e-p); this is not equal to the absolute spacing of model numbers
around zero because zero has e == 0, so b**(e-p) provides a much larger
value than expected.

ANSWER: Yes.

Discussion: Since the smallest magnitude model numbers are TINY(X) and
-TINY(X), the absolute spacing around zero is TINY(X). It was intended
that the "otherwise" clause of the SPACING definition apply to this case.

REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.7.1 and 13.13.100.

EDIT(S): In section 13.13.100, after "Result Value." change "The" to "If
X is not zero, the". In the same section, change "; otherwise " to
". Otherwise".

SUBMITTED BY: J.K.Reid

HISTORY: WG5/N786a item 234/7, N815a item 6 (X3J3/92-136 item 6)
         Approved as X3J3/92-171 at meeting 122 by a vote of 22-0
         Edit approved in 92-267r at meeting 123

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

NUMBER: 000065
TITLE: Block and Nonblock DO Construct
KEYWORDS: block DO construct, nonblock DO construct
DEFECT TYPE: Interpretation
STATUS: X3J3 approved; ready for WG5

QUESTION: Consider the following DO loop:

          DO 10, I = 1, 10
             K = I
   10     CONTINUE

It can be parsed using either of the following two paths:

  R816  <do-construct>                  is  <block-do-construct>

  R817  <block-do-construct>       		is  <do-stmt>
                                                 <do-block>
                                                 <end-do>

  R818  <do-stmt> 		                is  <label-do-stmt>

  R819  <label-do-stmt>               	is   DO <label> [<loop-control>]

  R821  <loop-control>              	is  ,<do-variable> =
                                                 <scalar-numeric-expr>,
                                                 <scalar-numeric-expr>

  R822  <do-variable>                	is  <scalar-variable>

  R823  <do-block>                    	is  <block>

  R801  <block>                        	is  [<execution-part-construct>]...

  R209  <execution-part-construct>		is  <executable-construct>

  R215  <executable-construct>     		is  <action-stmt>

  R216  <action-stmt		            is  <assignment-stmt>

  R824  <end-do>                      	is  <continue-stmt>

  R816 <do-construct>                	is  <nonblock-do-construct>

  R826  <nonblock-do-construct> 		is <action-term-do-construct>

  R827  <action-term-do-construct>		is  <label-do-stmt>
                                                 <do-body>
                                                 <do-term-action-stmt>

  R819  <label-do-stmt>             	is  DO <label> [<loop-control>]

  R821  <loop-control>              	is  ,<do-variable> =
                                                 <scalar-numeric-expr>,
                                                 <scalar-numeric-expr>

  R822  <do-variable>               	is  <scalar-variable>

  R828  <do-body>                    	is  [<execution-part-construct>]...

  R209  <execution-part-construct>		is  <executable-construct>

  R215  <executable-construct>    		is  <action-stmt>

  R216  <action-stmt>             		is  <assignment-stmt>

  R829  <do-term-action-stmt>     		is  <action-stmt>

  Constraint:  A <do-term-action-stmt> must not be a <continue-stmt>...

How is a compiler to decide that the above DO loop is obeying the rules
for a  <block-do-construct> (and thus no diagnostic is required) or that
it is following  the rules for a <nonblock-do-construct> (and thus by 1.4
it should report that the  program is being rejected because it is
violating the constraint)?

ANSWER:  The intent of the cited constraint is to remove the ambiguity
raised in the  question in favor of the <block-do-construct>
interpretation.

Discussion: Item 5 in section 1.5.1 states that

     The syntax rules are not a complete and accurate syntax description
     of Fortran, ...; where a syntax rule is incomplete, it is accompanied
     by the corresponding constraints and text.

This is an application of this rule.

REFERENCES: ISO/IEC 1539:1991 (E) sections 1.5.1, 2.1, and 8.1.

EDIT(S): None.

SUBMITTED BY: L. Rolison X3J3/92-126

HISTORY: Approved as X3J3/92-169 at meeting 122 by a vote of 20-0
                   Edit approved in 92-267r at meeting 123

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

NUMBER: 000066
TITLE: Declaration of FUNCTION type
KEYWORDS: function, declarations
DEFECT TYPE: Erratum
STATUS: X3J3 approved; ready for WG5

QUESTION: In the following example:

          SUBROUTINE SUB
            ...
            Y=F(X)
            ...
            CONTAINS
              FUNCTION F(X)
                REAL F,X
                  ...
              END FUNCTION F
          END

Is the declaration of function-name "F" in the REAL <entity-decl-list>
legal? Does the second constraint in 5.1 contradict the text in the first
sentence of the first paragraph after constraints in section 12.5.2.2?

ANSWER: Yes. The example above is standard conforming. There is no
conflict between the constraint and the text mentioned.

Discussion: The information in section 5.1 that applies to functions
describes functions being called, not functions being defined by program
units or by internal functions. The information in section 12.5.2.2
describes the definition of functions.

However, this distinction has been made less clear by syntax rules and
constraints in section 5.1 that do not reflect it. The supplied edit
remedies this situation by using consistent terminology and eliminating
the resultant redundant constraint.

REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1 (R504) and 12.5.2.2

EDIT(S):

   1. Change R504 "<function-name>{(<array-spec>)}" to "<function-name>".

   2. Change "Constraint: An <array-spec> for a <function-name> that does
      not have the POINTER attribute must be an
      <explicit-shape-spec-list>" to "Constraint: An <array-spec> for an
      <object-name> that is a function result that does not have the
      POINTER attribute must be an <explicit-shape-spec-list>".

   3. Delete the constraint "An <array-spec> for a <function-name> that
      does have the POINTER attribute must be a
      <deferred-shape-spec-list>".

SUBMITTED BY: L.R.Rolison X3J3/92-057 (121-LRR-4)

HISTORY: Original response in X3J3/92-090, reconsidered and rewritten
         Approved as X3J3/92-173 at meeting 122 by unanimous consent
         Approved in ballot 92-182

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

NUMBER: 000067
TITLE: Output of negative signed zero
KEYWORDS: F edit descriptors, negative signed zero, formatted output
DEFECT TYPE: Interpretation
STATUS: X3J3 approved; ready for WG5

QUESTION: If the real variables A, B, C, and D have the values -.003,
-.003, -0.0, and 0.0 respectively  and they are written with:

          WRITE(6,100) A,B,C,D
   100    FORMAT(F10.2, F10.3, 2F10.3)

is the following output correct:

     -0.00    -0.003       0.0       0.0
.........1.........2.........3.........4

ANSWER: No.

QUESTION: or should it be

      0.00    -0.003     0.000     0.000
.........1.........2.........3.........4

ANSWER: Yes. Negative signed zero in an output record is prohibited by
section 10.5.1 item (3). Truncation of trailing zeros by F edit
descriptor is not allowed. See the last paragraph of section 10.5.1.2.1.

REFERENCES: ISO/IEC 1539:1991 (E) sections 10.5.1 and 10.5.1.2.1

EDIT(S): None.

SUBMITTED BY: A.D.Tait X3J3/92-045 pp 14-16

HISTORY: Approved as X3J3/92-074 at meeting 122 by a vote of 22-0
                   Approved in ballot 92-182

--------------------------------------------------------------------------
NUMBER: 000068
TITLE: Pointer association status
KEYWORDS: pointer association
DEFECT TYPE: Erratum
STATUS: X3J3 draft response

QUESTION: When the execution of a procedure is terminated by the
execution of a RETURN or END statement, the pointer association status of
a pointer declared or accessed in the procedure becomes undefined unless
one of the exceptions listed in section 6.3.3.2 of the standard applies.

In the following example, when SUB is terminated, X remains associated
because it is in a COMMON block.  Pointer Z will become undefined.  The
Y in the main program is useful, but according to the standard, it is
invalid because it points to the undefined Z.  Is this correct?

            COMMON /COM/ X,Y
            CHARACTER*10,POINTER::X,Y
            ...
            CALL SUB
            PRINT *, X         ! X must be valid
            PRINT *, Y         ! is this Y valid?
          END

          SUBROUTINE sub
            COMMON /COM/ X,Y
            CHARACTER*10,POINTER::X,Y,Z
            ALLOCATE (X,Z)
            X = 'A STRING'
            Z = 'ANOTHER'
            Y => Z
            RETURN
          END

ANSWER: No, the interpretation suggested in the question is not correct.
The example is valid.

Discussion: The question appears to confuse the association status of the
pointer and the definition status of its target.  The pointer association
status of Z becomes undefined on the execution of the RETURN statement in
the above example, but this does not imply that the target of Z becomes
undefined.  The situation is analogous to that described in section
6.3.1.2 of the standard in the context of the ALLOCATE statement.

     If the previous target had been created by allocation, it becomes
     inaccessible unless it can still be referred to by other pointers
     that are currently associated with it.

An example and further elaboration is given in section C.6.4

     The basic principle is that ALLOCATE, NULLIFY, and pointer
     assignment primarily affect the pointer rather than the target.
     ALLOCATE creates a new target but, other than breaking its
     connection with the specified pointer, it has no effect on the old
     target.  Neither NULLIFY nor pointer assignment has any effect on
     targets.

Similarly, the target of Z in the above example is not affected when the
pointer association status of Z becomes undefined.  If the old target of
Z could not be referred to by other pointers, then it would become
inaccessible (though still technically defined).  In this example, the old
target of Z can still be referenced by Y.  It therefore remains both
defined and accessible.

The statement in section 14.6.2.2 that "The definition status of a pointer
is that of its target" applies only when the pointer is associated with a
target.

REFERENCES: ISO/IEC 1539:1991, sections 6.3.1.2, 6.3.3.2, 14.6.2.1, C.6.4

EDIT(S): The list in section 14.6.2.1, item (3), of ways that pointer
association status can become undefined is incomplete.  

In section 14.6.2.1, item (3), add a new subitem as follows:

  (e) After the execution of a RETURN or END statement in a procedure
      where the pointer was either declared or, with the exceptions 
      described in 6.3.3.2, accessed.

The reference to section 6.3.3.2 in 14.6.2.1 (3) (d) is misleading. 
In section 14.6.2.1, item (3), subitem (d), remove "6.3.3.2,".

SUBMITTED BY: Y.Yoshida, X3J3/92-051 p4
HISTORY: Approved as X3J3/92-083A at meeting 122 by a vote of 18-2
	Approved in X3J3/92-329 at meeting 123 (unanimous consent)

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

NUMBER:  000069
TITLE:  I/O implied DO variable
KEYWORDS:  implied DO, I/O statement
DEFECT TYPE: Erratum
STATUS: X3J3 draft response 

QUESTION(S):
    1) Can the "do-variable" in an implied-DO in an I/O statement
       be a sub-object?

    2) Should the second constraint in section 9.4.2 read:
       "Constraint: The "do-variable" must be a named scalar variable
        of type integer, default real, or double precision real."?

ANSWER(S): 
    1) No.  The intent of the committee was to allow only named scalar
       variables as "do-variables".  The supplied edit corrects this error.

    2) Yes, it should have.

Discussion:
    In FORTRAN 77, all implied-DO variables were required to be a "variable",
    and derived types were not part of the language.  The rules for implied-DO
    variables and DO loop "do-variables" were identical.
    The committee's intent was to permit only simple variables (named scalar
    variables) as implied-DO variables in I/O statements.

REFERENCES: ISO/IEC 1539:1991 (E) sections 8.1.4.1.1, 9.4.2, 5.2.9,
            ANSI X3.9-1978 12.8.2.3, 11.10, 9.3.

EDITS: In section 9.4.2, in the second constraint, replace the word
       "scalar" with "named scalar variable".

SUBMITTED BY: Larry Rolison, 92-086 (121-86/121-LRR-9)

HISTORY: 92-086
	Approved as X3J3/92-217b at meeting 123

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

NUMBER: 000070
TITLE: Characteristics specified by interface bodies
KEYWORDS:
DEFECT TYPE: Erratum
STATUS: X3J3 draft response

QUESTION: Section 12.3.2.2 indicates that an interface body specifies
all of a procedure's characteristics and that the characteristics must
be consistent with those in the procedure definition.  Are the following
code fragments standard conforming?

(a)   PROGRAM FRED
       INTERFACE
        SUBROUTINE SUB (ARR,J)
         INTEGER ARR(1:)
        END SUBROUTINE
       END INTERFACE
       INTEGER ARR(10)
       CALL SUB(ARR,2)
      END PROGRAM
        
      SUBROUTINE SUB(ARR, J)
       INTEGER ARR(J:)
       ...
      END SUBROUTINE SUB
        
(b)   FUNCTION C1( )
       CHARACTER(*) C1
       ...
      END FUNCTION C1
      FUNCTION C2(N)
       CHARACTER(N) C2
       ...
      END FUNCTION C2

      SUBROUTINE CALLER( )
       INTERFACE
        FUNCTION C1( )
         CHARACTER(*) C1
        END FUNCTION
        FUNCTION C2(N)
         CHARACTER(2) C2
        END FUNCTION
       END INTERFACE
       CHARACTER(5) CC
       CC=C1( )//C2(2)
       
ANSWER:

(a) This example is standard conforming.
(b) This example is not standard conforming.

Discussion:

(a) 12.2.1.1 states that the characteristics of a dummy data object include 
its shape, and that if the shape is assumed then that is a characteristic. 
Section 2.4.5 states that the shape of an array is determined by its rank and 
extent in each dimension (but not by its bounds, 15.1.2.4.2). Therefore the 
characteristics of SUB specified in the interface body are consistent with 
those in the definition of SUB, and the program is standard conforming.

(b) Section 12.2.2 states that the characteristics of a function
include whether or not the function result value is a character of
assumed length.  So the interface body for function C1 must indicate
that C1 is of assumed length.  However, item (3) in 5.1.1.5 indicates
that scoping units that invoke an external character function of assumed
length must have access to a definition of the function with a length type
parameter value other than *.  An edit is included to clarify this 
restriction.

In addition, the interface for C2 does not conform to the standard as the
length of C2 specified as 2 is not consistent with the length specified as
N within the function definition.

EDITS:
In section 5.1.1.5 item (3), add to the end: "Note that the interface for such
a function cannot be specified in an interface body."
   
REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 
12.2.1.1,
        and 12.2.2.
        
SUBMITTED BY: Graham Barber (a)
              Janice Shepherd (b)
                
LAST SIGNIFICANT CHANGE: 1992 11 11, new

HISTORY: Question (a) originally posed in X3J3/92-264.
         Question (b) originally posed in e-mail collection X3J3/92-46.
         Response proposed in X3J3/92-283.

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

NUMBER: 000071
TITLE: USE association and COMMON block names
KEYWORDS: use association, COMMON block names, storage association
DEFECT TYPE: Erratum
STATUS: X3J3 draft response

QUESTION: Can a module or subprogram access through USE association
variables declared in different modules to be in the same common block?

Example:

      MODULE MOD1
      COMMON /BLOCK/ A,B,C
      END MODULE MOD1

      MODULE MOD2
      COMMON /BLOCK/ X,Y,Z
      END MODULE MOD2

      SUBROUTINE USER()
      USE MOD1
      USE MOD2
      ...
      Y = A               ! Are both Y and A accessible?
      END

ANSWER: Yes.

Discussion: The COMMON statement in MOD1 forms a common block storage
sequence as described in 5.5.2.1.  The COMMON statement in MOD2 similarly 
forms a common block storage sequence.  These two sequences are associated as 
described in 5.5.2.3, thus associating A with X, B with Y, and C with Z.  The 
USE statements in USER make these variables accessible in that scoping unit.  
The associated variables are considered to behave as though they had been 
EQUIVALENCEd.  The list of entities made accessible by USE association in 
11.3.2 includes variables but not common blocks, so there is no implication 
that these two specifications of common block storage sequences for /BLOCK/ 
interfere with each other or require a concatenated common block storage 
sequence in USER.

Various other combinations of USE association, host association, and local
COMMON statements can similarly result in common associated variables being
accessible in the same scoping unit.  One of these cases, that involve
USE association and local COMMON statements, is prohibited in 5.5.2.5.

The edits below emphasize the independence of common block storage sequence
formation from USE and host association and eliminate the ineffective
restriction in 5.5.2.5.

REFERENCES: ISO/IEC 1539:1991 (E) sections 5.5.2.1, 5.5.2.3, 5.5.2.5, and 
11.3.2

EDITS:
  1. In the first sentence of 5.5.2.1 after "For each common block", insert
     "in a scoping unit".
  2. At the end of 5.5.2.1, add the following paragraph:
       "Only COMMON statements and EQUIVALENCE statements appearing in the
        scoping unit contribute to common block storage sequences formed in
        that unit.  Variables in common made accessible by USE association or
        host association do not contribute."
  3. At the end of the first paragraph of 5.5.2.3, add the following sentence:
     "USE association or host association may cause these associated objects
     to be accessible in the same scoping unit."
  4. Delete the last two sentences in 5.5.2.5.

SUBMITTED BY: Jon L. Steidel, 120-JLS-8

LAST SIGNIFICANT CHANGE: 1992 11 12, added edits to previously proposed 
interpretation

HISTORY: 120-86 (120-MBSH-3), initial response draft
         92-163, revised draft response
         92-191, revised draft response
         92-316, revised draft response - approved by a (19-2) vote at 
meeting 123

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

NUMBER: 000072
TITLE: Missing constraint for SIZE=
KEYWORDS:
DEFECT TYPE: Erratum
STATUS: X3J3 draft response

QUESTION: In section 9.4.1, should there be an additional constraint:

    "If a SIZE= specifier is present, an ADVANCE= specifier also must appear"?

ANSWER:  Yes.

      In reading the first two paragraphs of section 9.4.1, on page 120,
      immediately following the list of constraints, it can be seen that SIZE
      and EOR have the same requirements and, thus, there should be a
      constraint for SIZE that parallels the constraint (last in the list)
      for EOR.

REFERENCES:
            ISO/IEC 1539:1991 (E) sections 9.4.1

EDIT: Section 9.4.1, [120:25], add a constraint to the end of list:

      "If a SIZE= specifier is present, an ADVANCE= specifier also must 
appear."

SUBMITTED BY: Dick Weaver

HISTORY: 92-193

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

NUMBER: 000073
TITLE: Description of the MERGE intrinsic function
KEYWORDS: MERGE, intrinsic, elemental, array
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress

QUESTION: The MERGE intrinsic function is described as an array construction
function in 13.8.6, page 187, and in 13.10.16, page 191.

The description of MERGE, 13.13.67 page 220, classes it as elemental.

Are the 13.8.6 and 13.10.16 descriptions of MERGE consistent with its
classification as an elemental function?  Note that 13.8 is "Array intrinsic
functions" and MERGE is the only elemental included.  Should all elemental
functions be listed as "array construction" functions or should MERGE be
described elsewhere?


ANSWER: No; the classification of MERGE, and possibly other intrinsic
functions, for description purposes is not consistent.  This issue will
be addressed in the next revision.

REFERENCES: ISO/IEC 1539:1991 (E) sections 13.8.6, 13.10.16, 13.13.67

EDIT: None

SUBMITTED BY: Dick Weaver
LAST SIGNIFICANT CHANGE: 92 11 11, first draft response
HISTORY: X3J3/92-197
	Draft response in X3J3/92-322 at meeting 123, not approved

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

NUMBER: 000074
TITLE: Meaning of "referenced" in 11.3.2
KEYWORDS: local names, data entity
DEFECT TYPE: Erratum
STATUS: X3J3 draft response

QUESTION: 

The section of the standard in 11.3.2 [158:27-31] states:

     "Two or more accessible entities, other than generic interfaces,
     may have the same name only if no entity is referenced by this
     name in the scoping unit."

Should the use of this name as an argument to an inquiry function
also be disallowed; or passing the duplicate name as an argument be 
disallowed; or the duplicate name in a pointer assignment be 
disallowed?  Can the duplicate name be the left hand side of
an assignment statement?

Question 2:  Is it valid to have two local-names on a rename-list that
are the same but refer to two different data entities?  In the
following example, is the appearance of the second AA local-name in 
the rename-list legal?

          USE MID, AA=>BB
          USE MID, AA=>CC

ANSWER: 
Answer 1: The cases cited in the question are not covered specifically in 
11.3.2 although they were intended to be included in the quoted text as
"referenced" entities. The cited cases are examples of the appearance of 
names rather than as a technical Fortran 90 term for "reference".

Answer 2: The example is invalid. The appearance of the second
AA is not allowed by the standard. In section 11.3.2 [158:15-16],
the standard states that the local name is a "local name for the entity"
which was intended to mean that a new entity is not created, the
existing entity is just renamed.

Discussion:

It was intended that the term "referenced" be used in the 
sense that an entity "appeared in" or "is referred to" in the
scoping unit, and did not mean "referenced" in terms of the technical
definition. That is, two  or more accessible entities with the same 
name must not appear in the  same scoping unit. An edit has been made
to the standard to improve this wording.

REFERENCES: ISO/IEC 1539:1991 (E) section 11.3.2

EDIT(S):  
In section 11.3.2 [158:28] change the term "no entity is referenced by 
this name" to "the name is not used to refer to an entity".

SUBMITTED BY: Dick Weaver, 92-198 question raised. 
HISTORY:
Response draft in meeting 123 (92-297) - 
approved by unanimous consent in meeting 123.

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

NUMBER: 000075
TITLE: Interface blocks in block data
KEYWORDS: interface block, block data
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress

QUESTION:  In section 12.3.2.1, on page 167, the 3rd constraint

   "An interface-block must not appear in a BLOCK DATA program unit"

is constraining what? (The existence of a constraint implies that, if the
constraint were not present, the constrained "action" would be allowed.)

ANSWER:  The constraint is redundant with the 2nd constraint in section
11.4 on page 162.


REFERENCES:  ISO/IEC 1539:1991 (E) sections 11.4, 12.3.2.1

EDIT: None

SUBMITTED BY: Dick Weaver
LAST SIGNIFICANT CHANGE: 92 11 11, first draft response
HISTORY: X3J3/92-200
	Draft response in X3J3/92-323 at meeting 123, not approved

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

NUMBER: 000076
TITLE: Attributes, Properties, Characteristics
KEYWORDS:
DEFECT TYPE: Erratum
STATUS: X3J3 consideration in progress

QUESTION:  I've been trying to understand "attributes" and "properties".
Beginning with the glossary definition of "attributes":

      Attributes: A property of a data object that may be specified in
                  a type declaration statement

There would seem to be some set of "properties", of which a subset are
"attributes".  However, in trying to use that definition while reading
the standard, I had a variety of difficulties:

      -- that defintion itself:  data entities besides data objects have
         attributes and the attributes of a function result can be specified
         in a type declaration stmt in the same manner as for a data object.

      -- the first pp of chapter 5 equates attributes and properties
         "Collectively, these properties are termed the attributes of the
         data object"

      -- the introduction (xv, 2pp from bottom) equates attributes and
         properties: "... given the desired properties (attributes)"

      -- where I would expect "properties", I find "attributes", for example
         in host association 12.1.2.2.1 "The accessed entities are known
         by the same name and have the same attributes ....".  For host
         association, can the attributes be the same but properties be
         different?

      -- chapter 4, 4.4.2 for example, talks about derived type definitions
         having the SEQUENCE property but a derived type definition is not
         a data object.  (File and file connections also have properties;
         that usage, however, is clearly separate from data entities)

My questions:

    Data objects in Fortran 90 have (1st pp section 5)
                -- attributes
                -- properties
                -- characteristics (see also 12.2.1.1)

    (1) What is the relationship between attributes, properties, and
        characteristics?

    (2) Is this complexity, which seems to have led to a number of
        difficulties, necessary?


ANSWER:

(1) The intended relationships:

    attributes -- Going by the 1st pp of section 5, attributes are
            type plus those things that can be specified in both a
            type declaration statement and a separate specification
            statment (DIMENSION, for example).

    properties -- those things derived from attributes or that could
            be specified in a separate specification statement but
            not in a type statement.  Also, having
            or not having a value is a property (glossary entry "defined").

            The "array property", for example, is derived from
            the dimension attribute.

            The only property specifiable in a separate specification
            statement is SEQUENCE.

     characteristics -- This word is used only a few times in discussions
            of data objects and was likely used as "normal English".
            Unfortunately, "characteristics" is used in a technical way
            in chapter 12; that usage is disjoint from chapter 5.

(2) No, this complexity is not necessary.

The use of "characteristics" is readily removed.

Fortran 90 is not dependent on the distinction between "properties" and 
"attributes".  The distinction would seem to be only an artifact of defining 
attributes in terms of specific specification statements and thus needing 
another term for "attributes" not so specified.   While this may have 
simplified the definition of attributes it has, as you've noted, added 
complexity to the language definition and resulted in errors in the standard 
itself.

To correct this we will:

    -- consolidate "attributes" and "properties" into a single concept,
       "attributes".

    -- explicitly list the attributes a data entity may have and how
       those attributes can be specified.


REFERENCES:
            ISO/IEC 1539:1991 (E), X3J3/92-305, X3J3/92-307

EDIT:

page xv pp beginning "Section 4 (Intrinsic"
   delete "the properties of" [xv]
   change "and properties" to "and attributes" [xv]

page xv pp beginning "Section 4 also"
   change "properties" to "concepts"

   Note: this change is consistent with prior pp "Note that only type
   concepts ..."

page xv pp beginning "Section 5"
   change "properties(attributes" to "attributes" [xv]

page xvii
   change "scope properties" to "scopes" [xvii]

1.5.3
   change "Syntax conventions and characteristics"
       to "Syntax conventions" [5:2]

   rationale" eliminate spurious "characteristics"

2.3.1 page 11 2nd pp
   change "configure" to "specify"  [11:10]

   rationale: that is why most are called specification statements.
   This change is being made in conjunction with the change to 2.4.

2.4 page 13
   change "define the characteristics of" to "specify" [13:2]

2.4.1.1 page 13 1st pp
   change "The properties of intrinsic" to "Intrinsic" [13:11]

2.4.7 page 15
   change "characteristics" to "properties"

   Rationale: consistent with 1.3.2, page 1.

4.4.2 page 35 2nd pp
   change "have the SEQUENCE property" to "specify SEQUENCE" [35:43]

   Rationale: derived data type definitions are the subject and they
   are not data objects and thus do not have attributes.

4.4.2 page 35 2nd pp
   change "with the SEQUENCE property" to "with the SEQUENCE statement"  
   [35:45]

4.4.2 page 36 pp beginning "The actual"
   change "SEQUENCE property" to "SEQUENCE statement" [36:39-40]

5 page 39 1st pp
   replace entire pp with the following pp and table:

Every data entity has a number of attributes (for example, type, rank,
and shape) that determine the uses of the data entity.  Not all attributes
apply to every data entity; the SEQUENCE attribute,
for example, applies only to derived type data entities.  A named
data object or a function result must not be specified explicitly to
have a particular attribute more than once in a scoping unit.

 attribute        how specified for data objects and function results
 ---------        ------------------------------------------------------------
 type             either is determined implicitly by the first letter of
                    its name (5.3), or is specified explicitly in a
                    type-declaration-stmt
 accessibility    type-declaration or specification statement (PUBLIC,PRIVATE)
 ALLOCATABLE      type-declaration or specification statement
 array            derived from rank
 EXTERNAL         type-declaration or specification statement
 intent           type-declaration or specification statement (IN, OUT, INOUT)
 INTRINSIC        type-declaration or specification statement
 OPTIONAL         type-declaration or specification statement
 PARAMETER        type-declaration or PARAMETER statement
 POINTER          type-declaration or specification statement
 rank             type-declaration or specification statement (array-spec)
 SAVE             type-declaration or specification statement
 scalar           derived from rank
 SEQUENCE         SEQUENCE statement in the derived type definition
 shape            type-declaration or specification statement (array-spec)
 TARGET           type-declaration or specification statement
                                                              [39:3-9]

5.1.1.7 page 43 2nd pp
   change "SEQUENCE property" to "SEQUENCE attribute" [43:24]

5.1.2 page 43
   change heading "Attributes" to "Attribute specifiers" [43:31]

   Rationale: parallel construction to the 5.1.1 heading and necessary
   now that DIMENSION is not an attribute (array/scalar, rank and shape are).

5.1.2.1 through 5.1.2.11

   delete "attribute" from each heading [43:34 to 48:29]

   Rationale: parallel construction to  5.1.1.1 through 5.1.1.4 and
   necessary now that DIMENSION is not an attribute

5.1.2.4 page 46, 1st pp, sentence beginning "The DIMENSION"

   change "The DIMENSION attribute" to "DIMENSION" [45:2]

5.1.2.4 page 46, 1st pp, sentence beginning "The rank"

   change "DIMENSION attribute" to "DIMENSION specifier" [45:4]

5.1.2.4 page 46, 1st pp, sentence beginning "An array-spec"

   change "DIMENSION attribute" to "DIMENSION specifier" [45:5]

5.1.2.4 page 46, 1st pp, sentence beginning "If the DIMENSION"

   change "DIMENSION attribute" to "DIMENSION specifier" [45:6]

5.1.2.4 page 46, pp beginning "Examples"

   change "DIMENSION attribute specification" to "the DIMENSION specifier"
                                                         [45:13]

5.1.2.4.3 page 46 pp beginning "The size, bounds, and shape of an"
   delete "except as an argument to an intrinsic inquiry function that is
   inquiring about argument presence, a property of the type or type
   parameters, or association status". [46:26-27]

   Rationale: a reference, 2.5.5, is the appearance of the data object
   in a context requiring its value.  The exceptions above are not references.

5.1.2.4.3 page 46 pp beginning "The size, bounds, and shape of the target"
   delete "except as an argument to an intrinsic inquiry function that is
   inquiring about argument presence, a property of the type or type
   parameters, or association status". [46:31-33]

   Rationale: a reference, 2.5.5, is the appearance of the data object
   in a context requiring its value.  The exceptions above are not references.

5.2.5 page 50
   change "the DIMENSION attribute(5.1.2.4) and specifies the array  
           properties"
   to "rank or rank and shape attributes" [50:35]

5.2.9 page 51
   change "array properties" to "array attributes" [51:38]

5.2.10 page 53 1st pp
   change "properties" to "attributes" [53:39]

5.5.1 page 56 2nd pp
   change "properties" to "attributes" (two occurances) [56:37]

5.5.2 page 59 2nd pp
   change "properties" to "attributes" [59:4]

13.1 page 183 1st pp
   change "properties" to "attributes" [183:7]

glossary: array-valued
   change "property" to "attribute" [254:26]

glossary: attribute
   replace definition with "Attributes determine the uses of a data
                            entity (5)." [254:31]

   Note: alternately, list the attributes.

glossary: defined
   delete "the property of" [256:15]

glossary: explicit interface
   delete "the property of" [257:1]

glossary: inquiry function
   change "properties" to "attributes" [257:34]

glossary: scalar
   change "Not having the property of being an array"
       to "Having a rank of 0" [259:40]

glossary: undefined
   delete "the property of" [261:24]


SUBMITTED BY: Dick Weaver
HISTORY:      <meeting no.>        <information>
                              123                submitted as X3J3/92-202r
	Related question submitted in X3J3/92-248

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

NUMBER: 000077
TITLE: Misc. questions
KEYWORDS:
DEFECT TYPE: Erratum
STATUS: X3J3 consideration in progress

QUESTION:  In using the standard, I've noted a number of
corrections.  Are those corrections, expressed here as edits, right?

| rev 1: incorporates Bill Leonard's comments of 25 Sept.


Intro page xiii pp beginning "Computation involving..."
      change "entities" to "data entities"

2.4.3.1, 1st pp page 14
      change "but subobjects"
          to "but subobjects of named objects" [14:2]

      rationale:   '0123456789'(N:N) found on page 62, for example,
      is a constant subobject but is not referenced by a subobject designator.

2.5.6, 2nd pp page 16
       change "different entities"
           to "different data entities" [16:31]

       rationale: the concept of storage applies only to data entities.

4.3.1.2, 3rd pp page 28
       change "such an entity" to "such a data entity" [28:35]

       rationale: kind type applies only to data entities

4.3.1.3, 2nd pp page 29
       change "complex entity" to "complex data entity" [29:29]

       rationale: complex is a data concept; consistent with nearby text.

4.4.1, page 34 3rd pp
       change "any entity" to "any data entity" [34:9]

       rationale: other possibilities are covered in the rest of the
       sentence.

4.4.2, page 35 2nd pp
       change "an entity" to "a data entity" [35:46]

       rationale: only data is being discussed.

4.4.2 page 36 1st line
       change "entities" to "data entities" [36:1]

4.4.5 page 37
       change "entities" to "data entities" (2 occurrences) [37:30]

5 page 39
       change section 5 title from "Data object ..."
                                to "Data entity ..."

       Rationale: Entity declarations, see R504, are for data
       objects and for function results.  A function result is
       not a data object (2.4.3 and 2.4.3.1), but function results
       and data objects are data entities.

       Note that an effect of this change  is to
       align the title "Data entity declarations ..."
             with R504      "entity-decl"

5 page 39 1st pp
       change "every data object"
       to     "every data entity" [39:3]
       change "uses of the object" to "uses of the data entity] [39:4]
       Sentence beginning "Collectively" delete [39:4]

       (see prior rationale)

5 page 39 1st pp
       change "a named data object"
           to "a named data object or a function" (two occurrences) [39:5-6]

6.3.1 page 67
       change "entities" to "variables" [67:30]

       Rationale: only variables can be redefined or undefined

7.1.5 page 77 1st pp
       change "entities" to "data entities" [77:2]

7.1.6.2 page 79 pp beginning "If a specification..."
       change "an entity" to "a data entity"  [79:28]

7.1.7 page 80 pp beginning "The evaluation..."
       change "entity" to "data entity" [80:5]

7.1.7 page 80 pp beginning "For G..."
       change "entities" to "data entities" [80:11]

7.1.7 page 80 pp beginning "Execution of an ..."
       change "entity" to "data entity" [80:26]

7.1.7.1 page 81 pp beginning "Where X is ..."
       change "entities" to "data entities" [81:5]

7.5.3.2 page 93 last pp
       change "entities" to "data entities" (two occurrences) [93:41-42]

8.1.2.4 page 97 pp beginning "The execution of..."
       change "entities" to "data entities" [97:27]

9.1, page 109
       replace the sentence beginning "However, ..."
       with "However, a record as seen by a Fortran program does not
             necessarily correspond to a physical record on an
|            external medium." [109:19]

       Rationale: The existing sentence talks about "physical entity",
       but the Fortran "entity" concept has no physical realization.
       (i.e., this use of "entity" is not consistent with its Fortran 90
       definition).  If footnotes are used then this sentence, less the
|      "However,", would be much better as a footnote.

9.4.1, page 120 pp beginning "In a data transfer statement, the variable..."
       change "entity" to "variable" [120:33]

       Rationale: variables can only be associated with variables

9.4.2 page 123 1st pp
       change "entities" to "data entities" [123:18]

       Rationale: It is data entities that have a value.

9.4.4 page 125 item (5)
      change "entities" to "data entities"

9.4.4.1 page 125
       change "to the entities" to "to the variables" [125:28]

       Rationale: an input item that can receive a value is a variable

9.4.4.1 page 125
        change "from the entities" to "from the data entities" [125:30]

       Rationale: only data entities have values.

9.4.4.4 page 126 1st pp
       change "Data are transferred" to "Data is transferred" [126:10]
       change "and entities" to "and data entities" [126:10]
|      change "the entities" to "the name-value subsequences" [126:15]

|      Rationale: For "Data is transferred", collective nouns should be
|      accompanied by singular verbs when the collection is to be taken
|      as a unit.

9.4.4.4 page 126 2nd pp
       change "entities" to "data entities" [126:18]

9.4.4.4 page 126 3nd pp
       change "entities" to "data entities" [126:20]

9.4.4.4 page 126 pp beginning "All values following ..."
|      change "namelist entity (10.9) within the input records are
               transmitted to the matching entity specified in the
               namelist-group-object-list prior to processing any
               succeeding entity within the input record for
               namelist input statements"
|          to "name-value subsequence (10.9) within the input records are
               transmitted to the matching variable specified in the
               namelist-group-object-list prior to processing any
               succeeding name-value subsequence within the input record for
               namelist input statements" [126:24-26]

       Rationale: name-value subsequence is the term in the referenced text.
                  A namelist-group-object-list specifies variables,
                  see R544.

9.4.4.4 page 126 pp beginning "All values following ..."
       change "If an entity" to  "If a variable" [126:26]
       change "of the entity" to  "of the variable" [126:27]
       change "for that entity" to  "for that variable" [126:28]

       Rationale: R544, variables are specified.

9.4.4.4 page 126 pp beginning "An input ..."
|      change "an entity" to "a variable" [126:29]

       Rationale: variables can only be associated with variables

9.4.4.4 page 126 pp beginning "On output..."
       change "entity" to "data entity" [126:36]

       Rationale: only data entities have a value.

9.4.4.4.1 page 126 1st pp
       change "entities" to "data entities" [126:39]

9.4.4.4.1 page 126 bottom pp
       change "entity" to "variable" [126:44]

9.4.4.4.1 page 127 top
       change "real list entities" to "real variables" [127:1]
       change "complex list entity" to "complex variable" [127:2]
       change "corresponding entities" to "corresponding data entities"[127:2]
|      change "if an entity" to "if a variable" [127:3]
       change "character entity" to "character variable" [127:3]
       change "complex entity" to "complex variable" [127:5]
       change "real entities" to "real variables" [127:5]

9.4.4.4.2 page 127 1st pp
       change "data are transferred" to "data is transferred" [127:17]
       change "entities" to "data entities" [127:17]

9.6.2 page 134 1st pp
       change "entity" to "variable" [134:7}

       Rationale: variables can only be associated with variables.

13.5.4 page 184
       change "entity" to "data entity" [184:18]

13.5.5 page 184
       change "entity" to "data entity" [184:23]

13.10.5 page 189
       change "entity" to "data entity" [189:48]

13.13.53 page 214
       change "entity" to "data entity" [214:32]

glossary entry "entity"
      delete from definition the terms: a named variable, an expression,
         a component of a structure, a named constant
      add to definition the term "a data entity" [256:38-39]

      rationale: the terms deleted were not a complete replacement for
         "data entity".

glossary entry "main program"
      change "subprogram" to "external subprogram" [258:22]

      rationale: consistent with glossary entry for "program unit"

--------------------  end of question ---------------------------------------

ANSWER:

REFERENCES:
            ISO/IEC 1539:1991 (E) sections .....

EDIT:

SUBMITTED BY: Dick Weaver
HISTORY:      <meeting no.>        <information>
                              123               submitted as X3J3/92-203

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

NUMBER: 000078
TITLE: Intrinsic functions in MODULE specification statements
KEYWORDS: USE associated, intrinsic function, MODULE, specification expression
DEFECT TYPE: Interpretation
STATUS: X3J3 draft response

QUESTION: Consider a module that references an intrinsic function in a 
specification expression which declares a public data object in the 
specification part of the module.  Section 11.3.2 states

   "The local name of an entity made accessible by a USE statement may 
    appear in no other specification statement that would cause any 
    attribute (5.1.2) of the entity to be respecified in the scoping
    unit that contains the USE statement, except that it may appear in 
    a PUBLIC or PRIVATE statement in the scoping unit of a module."

The question centers on whether a scoping unit which uses such a module
gains access to the intrinsic procedure through use association.  
Specifically,
are the following two cases standard conforming?

     Case 1:
       MODULE SPEC
         PARAMETER (J = 3)
         DIMENSION ARRAY (IABS(10 - J)) ! Reference to IABS
       END MODULE

       PROGRAM USER
         USE SPEC
         REAL,DIMENSION (100)  :: IABS  ! Legal to respecify IABS?
         ...
       END

    Case 2:
       MODULE SPEC
         PARAMETER (J = 3)
         INTRINSIC IABS                 ! IABS explicitly declared INTRINSIC
         DIMENSION ARRAY (IABS(10 - J)) ! Reference to IABS
       END MODULE

       PROGRAM USER
         USE SPEC
         REAL,DIMENSION (100)  :: IABS  ! Legal to respecify IABS?
         ...
       END

ANSWER: Neither case is standard conforming.

Discussion:
In both cases, IABS denotes an intrinsic procedure in module SPEC.
Procedures are entities which may be made accessible by USE association,
and in the absence of a PRIVATE declaration applicable to IABS, they are
made accessible.  Thus, the cited restriction applies and the examples
do not conform.

REFERENCES: ISO/IEC 1539:1991 (E) section 11.3.2

EDIT: None

SUBMITTED BY: Jon Steidel
LAST SIGNIFICANT CHANGE: 1992 11 10, new
HISTORY: Initially drafted as X3J3/92-205
   Response in X3J3/92-278 - 
   approved by unanimous consent at meeting 123

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

NUMBER: 000079
TITLE: Automatic character and ALLOCATABLE, 
POINTER and TARGET attributes
KEYWORDS: Allocatable, automatic, array, character, 
pointer, target
DEFECT TYPE: Erratum
STATUS: X3J3 consideration in progress
     
QUESTION: Section 5.1 states:
     
   The specification-expr (7.1.6.2) of a type-param-value
   (5.1.1.5) or an array-spec (5.1.2.4) may be a nonconstant
   expression provided the specification expression is in an
   interface body (12.3.2.1) or in the specification part of a
   subprogram.  If the data object being declared depends on the
   value of such a nonconstant expression and is not a dummy
   argument, such an object is called an automatic data object.
   An automatic object must not appear in a SAVE or DATA
   statement nor be declared with a SAVE attribute nor be
   initially defined with an = initialization-expr.
     
Thus, a character object with a length-selector which is a
nonconstant type-param-value is an automatic object.
     
Section 5.1.2.9 states:
     
   The ALLOCATABLE attribute specifies that objects declared in
   the statement are allocatable arrays.  Such arrays must be
   deferred-shape arrays whose shape is determined when space is
   allocated for each array by the execution of an ALLOCATE
   statement (6.3.1).
     
The standard does not appear to prohibit allocatable arrays of
automatic objects.
     
Question 1: Is it the intent to allow allocatable arrays of
automatic character?
     
      FUNCTION FRED (J)
      CHARACTER(LEN=J),DIMENSION(:),ALLOCATABLE :: CH
      ALLOCATE (CH(100))
     
Question 2: If allocatable arrays of automatic objects are allowed,
is it correct to assume the array must not have the SAVE attribute?
     
Question 3: Character length is part of a character entity's type
and type parameters.  Was it intended that character entities whose
length is specified by a variable expression or a * (assumed length
character) be allowed to also have the POINTER or TARGET attribute?
     
The third constraint of Section 7.5.2 states
     
   The target must be of the same type, type parameters, and rank as
   the pointer.
     
In general, there should be no problem with allowing the POINTER and
TARGET attribute for automatic arrays.  However, there is a problem
if TARGET is intended to be allowed for automatic character, both
scalar and arrays, where the length is specified by a variable
expression.  Character length is part of the type and type
parameters, but where length is specified by a variable, the above
constraint cannot be diagnosed at compile time.  Was it the intent
to allow the TARGET attribute on any automatic objects, only on
automatic arrays except where character length is specified by a
variable expression, or for no automatic objects? If the intent is
to allow TARGET on all automatic objects, the above constraint must
be relaxed as it cannot be detected at compile time.
     
--------------------------------------------------------------------
     
FIRST POSSIBILITY:
     
ANSWER: The intent of the standard is to allow pointers and
allocatable arrays of character type whose length is specified by a
variable expression.  Such arrays must not have the SAVE attribute
specified.  The third constraint of section 7.5.2 cannot be
diagnosed at compile time and is relaxed by one of the supplied
edits.
     
REFERENCES: ISO/IEC 1539:1991 sections 5.1, 5.1.2.9, 7.5.2 and
14.7.5.
     
EDITS:
     
In the third constraint of section 7.5.2 delete ", type
parameters,".
     
Add at the beginning of the paragraph following the constraints of
section 7.5.2, "The target must have the same type parameters as the
pointer."
     
In 14.7.5, item (17), add at the end of the sentence, "unless the
object has the POINTER or ALLOCATABLE attribute".
     
--------------------------------------------------------------------
     
SECOND POSSIBILITY:
     
ANSWER: The intent of the standard is to prohibit pointers and
allocatable arrays of character type whose length is specified by a
variable expression.  An edit is supplied to clarify this
prohibition.  Also, the third constraint of section 7.5.2 cannot be
diagnosed at compile time for automatic character targets or targets
that are character dummy arguments with assumed length and,
therefore, is relaxed by one of the supplied edits.
     
REFERENCES: ISO/IEC 1539:1991 sections 5.1, 5.1.2.9, and 7.5.2.
     
EDITS:
     
Section 5.1, add to the list of constraints: "The POINTER and
ALLOCATABLE attributes must not be specified for an automatic data
object."
     
In the third constraint of section 7.5.2 delete ", type
parameters,".  Add at the beginning of the paragraph following the
constraints of section 7.5.2, "The target must have the same type
parameters as the pointer."
     
     
SUBMITTED BY: Jon Steidel
LAST SIGNIFICANT CHANGE: 12 Nov 92 Both responses rejected at
                           meeting 123
HISTORY: Initially drafted as X3J3/92-206
         92-206b/"Second Possibility" rejected at meeting 123 (14-5)
           [less than INT(membership/2)+1]
         92-206b/"First Possibility" rejected at meeting 123 (9-9)

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

NUMBER: 000080
TITLE: Vector subscripts in masked array assignment statements
KEYWORDS: vector subscripts, WHERE statement, WHERE 
construct, array assignment
DEFECT TYPE: Erratum
STATUS: X3J3 draft response
     
QUESTION: Is there a restriction on vector subscripts in masked array 
assignments?
     
Question 1: Is it intended to allow vector subscripts in masked
array assignment statements?
     
Question 2: If the answer to question 1 is "yes", is the intent that
the following two programs are semantically equivalent; that is,
should they print the same results?
     
      PROGRAM ONE
      INTEGER, DIMENSION(5)  :: INDEX, J, K
      INDEX = (/ 1, 2, 3, 4, 5 /)
      J     = (/ 1, 2, 1, 1, 2 /)
      K     = (/ 1, 1, 2, 2, 2 /)
      WHERE (J == K)
        J(INDEX) = 0
      ELSE WHERE
        J(INDEX) = 1
      END WHERE
      PRINT *, J
      END
     
      PROGRAM TWO
      INTEGER, DIMENSION(5)  :: INDEX, J, K
      LOGICAL, DIMENSION(5)  :: MASK
      INDEX = (/ 1, 2, 3, 4, 5 /)
      J     = (/ 1, 2, 1, 1, 2 /)
      K     = (/ 1, 1, 2, 2, 2 /)
      MASK = J == K
      DO I = 1, 5
         IF (MASK(I)) J(INDEX(I)) = 0
      END DO
      DO I = 1, 5
         IF (.NOT.MASK(I)) J(INDEX(I)) = 1
      END DO
      PRINT *, J
      END
     
ANSWER: The answer to questions 1 and 2 is yes.
     
Discussion: Vector subscripts are allowed in masked array assignment
statements.  Section 7.5.3.2 describes the interpretation of vector
subscripts in <mask-expr> and in the <expr> of an <assignment-stmt>.
However, the interpretation of <variable> in <assignment-stmt> is
not completely defined.  If <variable> is an array section, for
example, and a nonelemental function reference occurs within a
<section-subscript>, the interpretation is not specified.  The edits
below correct this.
     
REFERENCES: ISO/IEC 1539:1991 (E) section 7.5.3.2, section 6,
section 6.2.2.
     
EDIT(S):
   In the second paragraph of section 7.5.3.2 after <expr> [93:29],
   add "or <variable>".
     
   In the third paragraph of section 7.5.3.2 after <expr> [93:34],
   add "or <variable>".
     
SUBMITTED BY: Jon Steidel
LAST SIGNIFICANT CHANGE: 92-11-13
HISTORY: Submitted as X3J3/92-207 at meeting 123
         Response in X3J3/92-291 approved at meeting 123 (UC)
     
--------------------------------------------------------------------------

NUMBER: 000081
TITLE: Pointer actual argument overlap
KEYWORDS: Pointer, target, actual argument, dummy argument, 
argument associated 
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress

QUESTION:  Section 12.5.2.9, Restrictions on entities associated with 
dummy arguments, clearly states that if there is partial or complete 
overlap between actual arguments associated with two different dummy 
arguments of the same procedure, the overlapping portions may not be 
defined, redefined, or undefined during the procedure execution.  
It goes on to say:

   This restriction applies equally to pointer targets.  For example , in

   REAL, DIMENSION (10), TARGET :: A
   REAL, DIMENSION (:), POINTER :: B, C
   B => A (1:5)
   C => A (3:9)
   CALL SUB (B, C)

   B (3:5) cannot be defined because it is part of the actual argument 
   associated with the second dummy argument.  C (1:3) cannot be defined
   because it is part of the argument associated with the first dummy 
   argument.  A (1:2) [which is B (1:2)] remains definable through the 
   first dummy argument and A (6:9) [which is C (4:7)] remains definable
   through the second dummy argument.

Unfortunately, this example and does not contain an explicit interface for 
the called subroutine, nor are there sufficient words to clearly state what
is meant by the words and example provided. 

Question 1: Do the above restrictions hold when both dummy arguments 
are non-pointers?  In this case the following interface describes SUB.

      INTERFACE 
        SUBROUTINE SUB (X, Y)
        REAL, DIMENSION (:) :: X, Y
        END SUBROUTINE
      END INTERFACE

Question 2: Same as question 1, only add the TARGET attribute to one 
or both of the dummy arguments. The following interfaces may 
describe SUB.

      INTERFACE 
        SUBROUTINE SUB (X, Y)
        REAL, DIMENSION (:), TARGET :: X, Y
        END SUBROUTINE
      END INTERFACE

or

      INTERFACE 
        SUBROUTINE SUB (X, Y)
        REAL, DIMENSION (:) :: X, Y
        TARGET X
        END SUBROUTINE
      END INTERFACE

Question 3: Do the above restrictions hold *upon entry* when both 
dummy arguments are pointers?  That is, *upon entry* to SUB, is it 
safe to assume that pointer dummy arguments do not have overlapping 
elements which may get defined during execution of SUB?  (I realize 
it is legal through pointer assignment for the pointers to become 
associated with the same target during execution of SUB, this question 
is only about assumptions on entry to SUB.)  The following interface 
describes SUB.

      INTERFACE 
        SUBROUTINE SUB (X, Y)
        REAL, DIMENSION (:), POINTER :: X, Y
        END SUBROUTINE
      END INTERFACE

Question 4: Same as question 3, but one dummy argument is a pointer, 
one has the target attribute.  *Upon entry* to SUB, is it safe to assume 
a pointer dummy argument does not point to any elements of a target 
dummy argument which get defined during execution of SUB, but 
during the execution of SUB such an association may come to exist?  
The following interface describes SUB.

      INTERFACE 
        SUBROUTINE SUB (X, Y)
        REAL, DIMENSION (:) :: X, Y
        POINTER X
        TARGET Y
        END SUBROUTINE
      END INTERFACE

Question 5: Two derived type dummy arguments each have a 
subobject (or a subobject of a subobject etc.) which are pointers 
with the same type, kind type parameter, and rank.  *Upon entry* 
to the subroutine, is it safe to assume such pointer subobjects do 
not have overlapping targets?  That is, in the following fragment, 
*upon entry* to SUB, is it safe to assume X%PTR_1 and Y%PTR_2 
cannot have overlapping target elements which get defined during 
execution of SUB?

       SUBROUTINE SUB (X, Y)
       TYPE A
         SEQUENCE
         REAL, DIMENSION(:), POINTER :: PTR_1
       END TYPE

       TYPE B
         SEQUENCE
         REAL, DIMENSION(:), POINTER :: PTR_2
       END TYPE

       TYPE (A) :: X
       TYPE (B) :: Y
     

Note: A form of the above was posted to f90interp.  The two 
responses are attached for reference.  I read 12.5.2.9 differently 
from John and Kurt, and they read it differently from one another. 

ANSWER:

Discussion:

REFERENCES: 

EDIT:

SUBMITTED BY: Jon Steidel
HISTORY: Submitted Meeting 123 X3J3/92-208 

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

NUMBER: 000082
TITLE: Host association, generic name
KEYWORDS:
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress

QUESTION: Consider the program fragment

         1        INTERFACE  F
         2           FUNCTION X(Y)
                    ...

         3        CONTAINS
                    ...
         4           INTEGER F(10)

         5           I = F(2)

Reading in 12.1.2.2.1, Host association:

     Stmt 4 defines F to be an object-name (item 5 in the list on page 164).

     Thus F is the name of a local entity and any entity of the host that
     has F as its nongeneric name is inaccessible (text following list on
     page 164).

     Therefore the generic name, F, in the host is accessible.

     With that, is F(2) in stmt 5 a reference to the generic name or to
     the array name?

ANSWER:

REFERENCES:
            ISO/IEC 1539:1991 (E) sections .....

EDIT:

SUBMITTED BY: Richard Weaver

LAST SIGNIFICANT CHANGE: , original requestor's draft

HISTORY:              <meeting no.>        <information>
	Submitted as X3J3/92-235
	Related question submitted in X3J3/92-209

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

NUMBER: 000083
TITLE: Generic Override of Intrinsic Procedure
KEYWORDS:
STATUS: X3J3 consideration in process

QUESTION:
Because we all like to look at example code, I'll start with that then point 
out what I'm looking for.  Consider if you will:

    INTERFACE sin
      REAL FUNCTION my_sin(x)
        REAL, INTENT(IN) :: x
      END FUNCTION 
    END INTERFACE

My question is this:  Can a generic interface that has the same name as an 
intrinsic procedure override an existing intrinsic procedure?  That is, can a
user provide a generic interface definition such as shown above where the
intent is to invoke the user routine MY_SIN when the generic name SIN is
referenced with an argument of type default real?

Now for some background:  The only reference I've been able to find anywhere
in the standard that hints that a user can extend an intrinsic procedure is 
the following sentence from 14.1.2.3:

    When an intrinsic procedure, operator, or assignment is extended,
    the rules apply as if the intrinsic consisted of a collection of
    specific procedures, one for each allowed combination of type,
    kind type parameter, and rank for each argument or operand.

I interpret this sentence to rule the above example to be NOT standard
conforming.  My reasoning is thus:  The portion of the sentence beginning 
"the rules apply..." tells me that there is a "hidden" generic interface 
for SIN that looks something like:

    INTERFACE SIN
      REAL FUNCTION default_real_sin(x)
        REAL, INTENT(IN) :: x  
      END FUNCTION
      REAL FUNCTION real_first_kind_sin(x)
        REAL(KIND=<some value>), INTENT(IN) :: x
      END FUNCTION
      REAL FUNCTION real_second_kind_sin(x)
        REAL(KIND=<some other value>), INTENT(IN) :: x
      END FUNCTION
      ...
      COMPLEX FUNCTION CSIN(x)
        COMPLEX, INTENT(IN) :: x  
      END FUNCTION
      ...
    END INTERFACE

We know from 11.3.2 that if a user supplies a generic interface with the name
SIN, such as in my first example, the user interface will be "unioned" with 
the "hidden generic intrinsic" interface.  By the rules of chapter 14 for 
determining which specific interface to invoke, it will be discovered that the
MY_SIN specific interface and the DEFAULT_REAL_SIN specific interface are 
ambiguous.  Thus, I conclude that a a user can NOT redefine the interface of 
an existing intrinsic procedure; a user can only EXTEND the interfaces (such 
as defining a specific interface for SIN that accepts an argument of type 
logical).  This conclusion is consistent with the rules for overloading 
intrinsic operators that prohibit a user interface from redefining, say, "+"
for two integer operands.  

Do you agree with my interpretation?

ANSWER:

Discussion:

REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 12.3.2.1, 14.1.2.3, and
				14.1.2.4.1

EDIT(S):

SUBMITTED BY: Larry Rolison

LAST SIGNIFICANT CHANGE:

HISTORY: Submitted as X3J3/92-210, meeting 123

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

NUMBER:  000084
TITLE:  Change masked array assignment constraint to prose
KEYWORDS:  masked array assignment, WHERE statement, 
WHERE construct, shape, constraint
DEFECT TYPE:  Erratum
STATUS:  X3J3 draft response

QUESTION:  

The first constraint following rule R743 on page 93 states:

    Constraint:  In each assignment-stmt, the mask-expr and the variable
                 being defined must be arrays of the same shape.

However, it may be impossible to determine that the mask-expr and the variable
being defined are of the same shape at compile time.  A program can be
constructed quite easily in which the shapes of these entities are determined 
dynamically at run time.  For example:

           INTEGER array_1(100), array_2(100), start, end
           READ(5,*) start, end, array_1, array_2

  	WHERE (array_1(start:end) .NE. 0)
       	      array_2(start:end) =			&
               	 array_2(start:end) / array_1(start:end)
	   ENDWHERE

The term "shape" is defined in section 2.4.5 Array (page 15) as follows:

    The shape of an array is determined by its rank AND ITS EXTENT IN 
    EACH DIMENSION, and may be represented as a rank-one
    array whose elements are the extents.

Since all constraints are intended to provide additional information to (or 
in some cases limit) the BNF syntax rules and are intended to be determinable 
at compile time, and since the extents of a mask-expr or variable in a masked
array assignment can not always be determined at compile time, this constraint
is in error and should be changed from a constraint to a prose restriction.

ANSWER: Yes, the constraint should be changed.

REFERENCES:

ISO/IEC 1539:1991 (E) sections 7.5.3.1 and 7.5.3.2, in particular the first
contraint following rule R743 on page 93.

EDIT:

  1. Delete the first constraint following rule R743 on page 93.  Use the 
     constraint body as the new first paragraph of section 7.5.3.2.

SUBMITTED BY:  Larry Rolison

HISTORY:      Submitted as X3J3/92-211 at Meeting 123.
                        Approved at meeting 123 (uc)

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

NUMBER:  000085
TITLE:  Nondefault Integer Data Type for UNIT=, RECL=, and REC= Specifiers
KEYWORDS:  unit, data type
DEFECT TYPE:  Interpretation
STATUS:  X3J3 draft response

QUESTION:  Rules R902, R905, and R912 allow any type of integer for UNIT=,
RECL=, and REC= respectively.  Should a nondefault integer data type be
allowed for these specifiers in the <io-control-spec-list>?

ANSWER:  Yes.  The standard is consistent in requiring default KIND scalar
integer variables in I/O statements when values are returned to the program
in such a variable.  When an integer value is required as the value for an
I/O specifier in any of <connect-spec-list>, <close-spec-list>,
<io-control-spec-list>, <position-spec-list>, and <inquire-spec-list>, but no 
value is returned for that specifier, then any KIND of scalar integer 
expression is consistently allowed.

REFERENCES: ISO/IEC 1539:1991 (E) section 9.3, 9.3.4, and 9.4.1

EDITS: None

SUBMITTED BY: Joanne Brixius X3J3/92-212

HISTORY:  Questions submitted as X3J3/92-212, X3J3/92-213, and X3J3/92-243
	Approved as X3J3/92-274 at meeting 123

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

NUMBER: 000086
TITLE: USE and Host Association
KEYWORDS:
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress - content challenged as incomplete

QUESTION:

 Use association, 11.3.2 page 158, states

   "The USE statement provides the means by which a scoping unit access
   named data objects, derived types, interface blocks, procedures,
   generic identifiers (12.3.2.1), and namelist groups in a module."

 Host association, 12.1.2.2.1 page 163, says

   "An internal subprogram, a module subprogram, or a derived-type definition
   has access to the named entities from its host via host association.
   The accessed entities are known by the same name and have the
   same attributes as in the host and are variables, constants, procedures
   including interfaces, derived types, type parameters,
   derived-type components, and namelist groups."

  Question 1: Do USE and host association access the same entities?
              What entities does each access?

  Question 2: For both USE and host association, what entities are
              not accessed?

  Question 3: For host and use association, if the host or module referenced
   contains an EXTERNAL statement for ABC, is ABC an accessed entity that has
   the EXTERNAL attribute?  Note that an EXTERNAL statement is not a "named
   entity" (the statement has no name) and the procedure named in the
   statement is not in the host or module (that is why the EXTERNAL  
   statement).

   The answer to question 1 or 2 should also answer this question.


  Question 4: given the following

       PROGRAM  A           |   MODULE M
         USE X              |    USE Y
                            |
       CONTAINS             |
         SUBROUTINE B       |
          USE M             |

    is subprogram B associated in some way with X?  What way?  Note that A,
    the host of B, "accesses" entities in X via USE association; the
    entities in X are not "in" B's host.


  Question 5: in the same example

    is subprogram B associated in some way with Y?  What way?  As with
    question 4 note that the entities in Y are "accessed" from M; the
    entities in Y are not in M and USE association is to the entities
    "in the module".

  Question 6: given the following:

       Module a     ! level 1 host

       use aa
       interface f
        ...
       contains

       subroutine b ! module subroutine, level 2 host
       use bb
       interface f
       ....

         contains
         subroutine c ! internal subprogram
         use cc
         interface f
         ...
         .... = f(x)  ! an invocation of the generic name f

    and where modules aa, bb, and cc all contain a generic interface for f:

    How is the invocation of the generic name f resolved? (in what sequence
    are which hosts and uses considered?)

    Note the levels of nesting:  a contains b contains c.  Section 14.1.2.4.1,
    Resolving procedure references to names established to be generic,
    (3), seems to consider only "b", the host of "c", and not "a".


ANSWER:

  Answer 1: Entities declared PRIVATE are potentially accessible by
    host association but not by USE association.  Otherwise, it was
    intended that the classes of entities made accessible by these two
    forms of association be the same.  These are named data objects
    (including both constants and variables), derived types (including
    the components of those types), procedures (both those defined in
    the host or module and those declared there and defined
    elsewhere; both those identified by names and those identified by
    other generic identifiers), and namelist groups.
    
  Answer 2: Entities not in the preceding list are not made accessible.
    For example, FORMAT statement labels, construct names, and common
    block names are not made accessible.
    
  Answer 3: In such an example, ABC would be accessible.  In the host or
    module, ABC would denote a procedure and thus be potentially an
    accessible entity; it is not necessary that the definition of ABC be
    present in the host or module.

  Answer 4: The entities of module X made accessible in A by USE association
    are made accessible in B by host association.  Note that each such
    entity has a local name (or other identifier) in A.

  Answer 5: The entities of module Y made accessible in M by USE association
    are made accessible in B by USE association.  Note that each such entity
    has a local name (or other identifier) in M.

  Answer 6: In effect, first c and cc are checked, then b and bb, then
    a and aa, and finally (if f were the generic name of an intrinsic
    function) the intrinsics.

    In applying 14.1.2.4.1 to a reference in c, item (1) provides the
    check of interfaces in c (including those made accessible from cc),
    and item (3) provides for a recursive application of 14.1.2.4.1 to
    b.  In this recursive application, (1) checks b (and bb), and (3)
    results in a further recursive application of 14.1.2.4.1 to a.  In
    this application, (1) checks a (and aa), (3) is not applicable, and
    (4) checks the intrinsics.

    14.1.2.3 establishes that there must be no ambiguity in distinguishing
    the interfaces declared in c from those made accessible from cc.

REFERENCES:
  ISO/IEC 1539:1991 (E) sections 11.3.2, 12.1.2.2.1, 14.1.2.3, and 14.1.2.4.1.

EDIT: none

SUBMITTED BY: Richard Weaver

LAST SIGNIFICANT CHANGE: 1992 11 10, new

HISTORY:  Submitted in X3J3/92-214
	Response proposed in 92-281 - meeting 123 
	(vote of 11-7 was insufficient for approval)

--------------------------------------------------------------------------
NUMBER: 000087

not assigned

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

NUMBER: 000088
TITLE: Common block names and local names
KEYWORDS: common block name, local name
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress

QUESTION: Section 12.1.2.2.1 says

    A name that appears in the scoping unit as

    (5) an object name in an entity-decl ...

    ... is the name of a local entity and any entity of the host that
    has this as its nongeneric name is inaccessible.


  Is this consistent with 14.1.2.1 "Common Blocks" ?


ANSWER: Yes.  Accessibility does not apply to common block names.

REFERENCES: ISO/IEC 1539:1991 (E) sections 12.1.2.2.1, 14.1.2.1.

EDIT: None

SUBMITTED BY: Dick Weaver

LAST SIGNIFICANT CHANGE: 92-11-11, first draft response

HISTORY: Submitted as X3J3/92-219
	Response proposed in X3J3/92-324, meeting 123
	(vote of 14-6 was insufficient for approval)

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

NUMBER: 000089
TITLE:  Errors in the DATA statement description
KEYWORDS:  DATA statement, data-stmt-value-list, data-stmt-constant
DEFECT TYPE:  
STATUS:  X3J3 consideration in progress

QUESTION:

The description of the values in the data-stmt-value-list on page  53, lines
4-20 contains a recurring flaw.  This section continually refers to the 
constant values in the list as simply "constants".  A structure constructor 
is not a constant; rather it is a constant expression.  This is demonstrated 
by:

    * The definition of "constant" in 2.4.3.1.2.  There are only two broad
      categories of constants defined:  named constants and literal constants.

    * The syntax rules for "constant" (page 20, rules R305-R309) reinforce  
      this definition by defining only two nonterminals:  literal-constant  
      and named-constant.

    * The description of the structure constructor on page 37 states:

          A structure constructor whose component values are all constant 
          expressions is a derived-type constant expression.


ANSWER:

Discussion:

REFERENCES:

EDIT:

Suggested edits:

   1. In rules R532 and R533, change "data-stmt-constant" to
      "data-stmt-constant-value".

   2. In the constraint that begins on line 26, change "data-stmt-constant" to
      "data-stmt-constant-value".

   3. The sentence beginning "Each such value..." on page 53, line 4 is an 
      analog to the second sentence in the constraint on page 52, beginning on
      line 23 and should likewise be made into a constraint.  We need not be
      concerned with adding any kind of constraint stating that if a constant
      list value is a structure constructor, the type definition must appear
      prior to the DATA statement because there are already other rules in
      place that cover this case.  The only case we need be concerned about
      is a named constant, which is the same as the repeat factor case.
      Thus, the changes are:

         a. Delete the sentence beginning "Each such value..." from page 53,
            lines 4-5.

         b. Delete the second sentence of the constraint on page 52,
            lines 23-25.

         c. Add a new constraint following the one on line 23:

              Constraint:  If the DATA statement repeat factor or constant
                           value is a named constant, it must have been
                           declared previously in the scoping unit or made
                           accessible by use association or host association.

   4. Page 53, line 6:  Change "following constant" to "following constant
      value".

   5. Page 53, line 11:  Change "constant" to "constant value".

   6. Page 53, line 17:  Change "constant" to "constant value".

   7. Page 53, line 18:  Change "constant" to "constant or structure
     constructor".

   8. Page 53, line 19:  Change "constant" to "constant or structure
      constructor".

SUBMITTED BY:  Larry Rolison

HISTORY:      Submitted as X3J3/92-221 at Meeting 123.

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

NUMBER: 000090
TITLE: Subroutine and Function names in nested scopes
KEYWORDS: procedure names, nested scopes
DEFECT TYPE: Interpretation
STATUS: X3J3 consideration in progress

QUESTION: Section 12.1.2.2.1 says

    A name that appears in the scoping unit as

    (2) a function-name in a function-stmt ...

    (3) a subroutine-name in a subroutine-stmt

    ... is the name of a local entity and any entity of the host that
    has this as its nongeneric name is inaccessible.  Entities that are
    local (14.1.2) to a procedure are not accessible to its host.

 1. If this is true, how can hosts reference internal procedures, module
    procedures and interface blocks (the text in 2.2.3.3 pertains only
    to internal procedures and is somewhat vague) ?

 2. Are entities local to an interface body accessible to the host?
    (i.e., should the "Entities that are local ..." rule above be
    more general?)

ANSWER:
 1. The text cited from sections 12.1.2.2.1 and 14.1.2 contains errors.
    In order to allow internal procedures and module procedures to be
    referenced as described in sections 2.2.3.2 and 2.2.3.3, such
    procedures must be local entities of their hosts.  Edits are
    provided to make this change.

    Additional rules are then needed to prevent the name of a module
    procedure or internal procedure from conflicting with the
    names of local entities within the procedure.  These rules are
    similar in purpose and form to those for external procedures
    and are included in the edits below.

 2. No, entities local to an interface body are not accessible to
    the host.  This is part of the more general rule stated in the
    first two paragraphs of section 14.

      "Entities are identified by lexical tokens within a scope..."

      "By means of association, an entity may be referred to... in a
       different scoping unit..."

    Thus, in the absence of association, an entity is not accessible
    in different scoping units.  The statement in section 12.1.2.2.1 that
    "Entities that are local (14.1.2) to a procedure are not accessible to
    its host" is a specific case of the general rule.  Although redundant,
    this specific elaboration is made for host association to clarify that
    host association is uni-directional.

    Host association does not apply to interface bodies.  The first
    sentence in section 12.1.2.2.1 lists the kinds of scoping units
    that have host association; this list does not include interface
    bodies.  The penultimate paragraph of section 12.1.2.2.1 makes it
    explicit that this omission was intentional.

    Note also that nothing references interface bodies (or interface
    blocks).  An interface body serves only to provide an explicit
    interface for a procedure as described in sections 12.3.1 and
    12.3.2.1.  It is the procedure, not the interface body, that
    may be referenced.

REFERENCES: ISO/IEC 1539:1991 (E) sections 2.2.3.2, 2.2.3.3, 12.1.2.2.1,
12.3.1, 14, 14.1.2

EDITS: In section 12.1.2.2.1, second paragraph, third sentence [164:1-2],
replace the initial word "A" with "The name of a contained internal
procedure or a".

In the second paragraph of section 12.1.2.2.1,
in item (2) [164:4], delete "in a function-stmt," and also
delete the comma preceding the "or".

Delete items (3) and (4) [164:6-7] and renumber the rest.

In item (1) of the first sentence of section 14.1.2 [241:24],
change "internal procedures" to "contained internal procedures"
and change "module procedures" to "contained module procedures".

Add a new paragraph after the second paragraph of section 14.1.2 [241:31+].
  "Within a scoping unit that defines an internal procedure or a
   module procedure, the name of the procedure must not be used to
   identify a global entity or a local entity of class (1) in that
   scoping unit."

SUBMITTED BY: Dick Weaver

LAST SIGNIFICANT CHANGE: 92-11-11, first draft response

HISTORY: Submitted as X3J3/92-220
	First draft response in X3J3/92-328

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