(j3.2006) (SC22WG5.4844) J3 interp letter ballot #27

[Robert Corbett]

The following Fortran interpretations are being balloted:

Yes  No   Number     Title

-Y-  ---  F03/0053   The BIND attribute for C_PTR and C_FUNPTR
-C-  ---  F08/0075   Pointer function reference as variable in assignment
-Y-  ---  F08/0083   Type parameter default expressions allow circular
                                dependence
-Y-  ---  F08/0084   Pointer arguments to PURE functions
-Y-  ---  F08/0085   Problems with PARAMETERs
---  -N-  F08/0086   Implied-shape and separate PARAMETER statement

-------------------------
F08/0075 C

As I pointed out in e-mail on 2012 May 18 and at meeting #199,
changing the boundary between expressions and variables changes
the semantics of the ASSOCIATE and SELECT TYPE constructs.  The
proposed edits result in semantics that are different from the
semantics of both Fortran 2003 and Fortran 2008 as published.
Text should be added to Clause 1.6.2 noting the semantic
difference between Fortran 2003 and the edited version of
Fortran 2008.  The answer should make note of the difference
between the original version of Fortran 2008 and the edited
version of Fortran 2008.

The example I gave in my e-mail was

       FUNCTION F(P)
         POINTER F, P
         F => P
       END

       PROGRAM ASSOC
         TARGET X
         POINTER P
         INTERFACE
           FUNCTION F(P)
             POINTER F, P
           END FUNCTION
         END INTERFACE
         X = 1.0
         P => X
         ASSOCIATE(Y => F(P))
           X = 2.0
           PRINT *, X, Y
         END ASSOCIATE
       END

In Fortran 2003, the selector in the ASSOCIATE statement is not
a variable.  Therefore, the associate name Y is associated with
the value of the expression F(P), not with the data object
named by X (see 16.5.1.6, paragraph 4 [446: 13-15] of the
Fortran 2008 standard or 16.4.1.5, paragraph 4 [413: 13-15 of
the Fortran 2003 standard).  Therefore, the assignment to X in
the ASSOCIATE construct does not change the value of Y, and so
the program prints " 2.0 1.0".

In Fortran 2008, with or without the edit, the selector is a
variable.  Therefore, Y is associated with the data object
named by X.  The assignment to X changes the value of the data
object with which Y is associated, and so the program prints
" 2.0 2.0".

-------------------------
F08/0086 N

The questions as given contain errors.  The brief answers given
do not make clear what aspect of the questions they are
answering.

Consider the code given in question Q2.  Almost anyone with a
nodding familiarity with Fortran would understand that the
program does not conform to the Fortran standard because b
is declared to be both Real and Integer.

Ignoring the conflicting type declarations, the declarations
of b and c are still troubling.  Both b and c are declared to be
rank one arrays (see 5.3.8.6, paragraph 2 [96: 28]).  The bounds
and extents  of a rank one array cannot be the same as those of
a scalar <constant-expr>.  I did not find a statement in the
Fortran 2008 standard that requires the <constant-expr> that
specifies the value of an implied-shape named constant to have
the same rank as the named constant, but there should be one.
The requirement should be a constraint.

The Fortran standards from Fortran 90 through Fortran 2008 have
allowed a single <array-spec> to denote more than one class of
array.  Consider the subroutine

       SUBROUTINE SUBR(A, P)
         REAL, DIMENSION(:) :: A, P, Q
         POINTER P, Q
       END

The <array-spec> in DIMENSION(:) is an <assumed-shape-spec>
for A and a <deferred-shape-spec> for P and Q.  The syntax is
ambiguous, but the meaning is clear from context.  I see no
reason to treat assumed-size and implied-shape arrays
differently.

Adding the requirement that an implied-shape array can appear
only in a type declaration statement that specifies the
PARAMETER attribute introduces an unnecessary inconsistency
to the language.  I have often seen code such as

       INTEGER A(3)
       PARAMETER (A = (/ 1.0, 2.0, 3.0 /) )

I think people would be confused to find that rewriting the
code as

       INTEGER A(*)
       PARAMETER (A = (/ 1.0, 2.0, 3.0 /) )

is not allowed.