(j3.2006) J3 Fortran interp letter ballot #26

[Robert Corbett]

The following Fortran interpretations are being balloted:

Yes  No   Number     Title

-C-  ---  F08/0040   MOVE_ALLOC for coarrays
-Y-  ---  F08/0074   Implicit type in BLOCK construct
---  -N-  F08/0075   Pointer function reference as variable in assignment
---  -N-  F08/0076   Pointer function reference in READ
-C-  ---  F08/0077   Function references as variables in DATA statements
---  -N-  F08/0078   Are the IEEE values +0 and -0 distinguished
---  -N-  F08/0079   NAMELIST and type specification
-Y-  ---  F08/0080   Array constructors with polymorphic values
---  -N-  F08/0081   Deallocation error handling
---  -N-  F08/0082   Generic identifier and dtv arguments

-------------------------
F08/0040 C

The answer says "the coranks of FROM and TO need to be the same."
The discussion says "the dummy arguments of MOVE_ALLOC do not
technically have corank."  I think I understand how both statements
can be true, but it did confuse me at first.  I suggest eliding the
statement from the discussion.

-------------------------
F08/0075 N

I am happy with the answer given, although I think the edit can be
simplified.  I am voting "no" because I think we should consider other
possible solutions.  I think the suggestion made by Rafik Zurob
during meeting 198 deserves further consideration.  He suggested
requiring an <expr> used as a variable to be a function reference.
That cannot be done in a blanket fashion without breaking
compatibility with Fortran 2003.  However, I think it can be done
if exceptions are made for a few cases.

-------------------------
F08/0076 N

My comments for F08/0076 also apply here.

-------------------------
F08/0077 C

Changes to the resolution of F08/0075 and F08/0076 might have an
effect on the edits given here.

-------------------------
F08/0078 N

I disagree with the interpretation.  I think that the distinction
between +0 and -0 is such an important component of IEC 60559:1989
that it should be required if IEEE_SUPPORT_DATATYPE is true.

-------------------------
F08/0079 N

I agree with the point raised in question Q4 that it is unclear
whether the requirement for confirmation is intended to apply to
length type parameters.  I think the problem is greater than
that.  The interpretation given here assumes that the namelist
group object is implicitly typed if the NAMELIST statement
precedes an explicit declaration of its type.  That assumption
is contradicted by paragraph 4 of Clause 5.5 [109:17-19].

The declared type of a namelist group object will be established
either by implicit or explicit typing.  Therefore, the only portion
of paragraph 5 of Clause 5.6 [111:19-23] that is required for types
and type parameters is the second sentence.  The first sentence is
needed only for the rank.

A possible rewrite of paragraph 5 of Clause 5.6 that resolves the
problems is

      If the rank of a namelist group object is specified
      by a specification statement in the same scoping unit
      as the NAMELIST statement, that specification statement
      shall precede the NAMELIST statement.  If the type of
      a namelist group object is explicitly declared by a type
      declaration statement in the same scoping unit as the
      NAMELIST statement and the NAMELIST statement precedes
      the type declaration statement, the explicit type and its
      type parameters shall match the type and corresponding
      type parameters that the implicit mapping for the scoping
      unit would assign the name of the namelist group object.

-------------------------
F08/0081 N

I continue to believe that the 4.5.6.3 means and should mean that
finalizers are invoked only after successful deallocations.  The
interpretation given is likely to lead to data structures left in
indeterminate states.  I think that will severely restrict what a
program can safely do after an error condition occurs during
deallocation.

-------------------------
F08/0082 N

There is a problem with the wording of the constraint.  The
definition of the term "generic identifier" is

      1.3.78
      generic identifier
      lexical token that identifies a generic set of procedures,
      intrinsic operations, and/or intrinsic assignments.

None of the alternatives for a <defined-io-generic-spec> (R1208)
is a lexical token.  Either the wording of the constraint needs
to change or the definition of a generic identifier needs to be
expanded.