04-316

Date: 6-May-2004
To:   J3
From: Interop/interp/Bill Long
Subj: Answer to interpretation # F90/000145


NUMBER: F90/000145
TITLE: Expressions in <type-spec> of a FUNCTION statement
KEYWORDS: expression - specification, expression - initialization,
          FUNCTION statement, host association, use association
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

The syntax rule R1217 shows that the type and type parameters of a
 function can be specified in the FUNCTION statement (12.5.2.2).

(a) If a <type-spec> appears in a FUNCTION statement, can the
initialization and specification expressions of that <type-spec>
involve names of entities that are declared within the function or are
accessible there by host or use association?

(b) 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."

As a FUNCTION statement is not part of the specification part of a
subprogram,  this text in the standard appears to distinguish between
FUNCTION statements that are in interface blocks and ones that are
not. This text seems to prohibit such examples as:

         INTEGER I
          ...
         CONTAINS
           CHARACTER*(I+1) FUNCTION F()
              ...
              COMMON // I
              ...

where it can be confusing as to which I is being referenced in the
FUNCTION statement.  While host association does not apply to
interface bodies, for consistency should the text quoted from Section
5.1 have been "... is in the specification part of an interface body
(12.3.2.1) or in the specification part of a subprogram."?

(c) Section 7.1.6.1 states:

      "If an initialization expression includes a reference to an
       inquiry function for a type parameter or an array bound of an
       object specified in the same <specification-part>, the type
       parameter or array bound must be specified in a prior
       specification of the <specification-part>."

Was this text intended to apply to FUNCTION statements even though
they are not qpart of any <specification-part>, thus disallowing
fragments such as:

        INTEGER (KIND=KIND(X)) FUNCTION F()
        INTEGER(KIND=KIND(0)) X
        ...

Similar text appears in Section 7.1.6.2.

ANSWER:


(a) A specification expression in the <type-spec> of a FUNCTION
statement may involve names of entities that are declared within the
function or are accessible there by host or use association, but an
initialization expression in such a <type-spec> may only involve names
that are accessible by host or use association.

(b) No. This was clarified in Fortran 1995.

(c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION
statements.  The sentence quoted and the corresponding sentence in
7.1.6.2 are corrected with supplied edits.  The code fragment is not
standard conforming.

EDITS:

1. Section 7.1.6.1, in the paragraph after the constraints [94:39-40]

    change "object specified in the same <specification-part>, the
             type parameter or array bound must be specified in
             a prior specification of the <specification-part>."

    to "object declared in the same scoping unit, the type parameter
            or array bound must be determined by implicit typing rules
            or explicitly specified prior to the initialization
            expression."

2. Section 7.1.6.2, in the 2nd paragraph after the constraint [96:33-34]

    change "entity specified in the same <specification-part>, the
             type parameter or array bound must be specified in
             a prior specification of the <specification-part>."

    to "entity declared in the same scoping unit, the type parameter
            or array bound must be determined by implicit typing rules
            or explicitly specified prior to the specification
            expression."

SUBMITTED BY: Janice C. Shepherd

HISTORY: 93-193   m126 submitted
         94-023r1 m128 response, approved uc
         94-116r1 m129 X3J3 ballot failed 22-1
         94-336   m131 revised response, approved u.c
         95-034r1 m132 X3J3 ballot failed 15-5
         95-281   m135 revised response, reworded edit 3, WG5
                         approved (N1161)
         96-      m136 X3J3 ballot failed 15-1, WG5 approval removed.
         04-316   m168 Submitted for J3 vote.