Yes  No Number     Title
--- --- F95/0098 Are dummy functions returning assumed-length character legal?
--- --- F03/0022 Coexistence of IEEE and non-IEEE kinds
--- --- F03/0024 DEALLOCATE and array pointers
-C- --- F03/0034 IEEE_LOGB()
--- -N- F03/0039 HYPOT()
--- -N- F03/0063 Procedure pointers in BLOCK DATA program units
--- --- F03/0071 Subroutine/function ambiguity in generics
--- --- F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence
--- -N- F03/0090 Polymorphic array constructors
--- --- F03/0112 Attributes allowed for dummy arguments in defined assignments
--- --- F03/0119 Elemental procedures and deferred length character components
--- --- F03/0122 When do objects of sequence derived type have the same type?
--- --- F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS
--- --- F03/0126 References to VOLATILE variables in pure procedures
--- --- F03/0127 Duration of procedure execution
-C- --- F03/0129 C_LOC of character substrings
--- --- F03/0130 Elemental specific intrinsic procedure characteristics
--- --- F03/0131 SAVE attribute and EQUIVALENCE
--- --- F03/0132 Unformatted i/o and private components
--- -N- F03/0133 Is unlimited polymorphic allowed in COMMON?
-Y- --- F03/0134 Implicit typing of procedure pointers
-C- --- F03/0135 Interaction between RESULT, recursion, and host generic
-Y- --- F03/0136 Are subroutines distinguishable from arrays?
-Y- --- F03/0137 Dummy procedure type compatibility
-C- --- F03/0138 External <procedure-name> as <proc-target>
-C- --- F03/0139 Functions returning procedure pointers
-Y- --- F03/0140 Type of nested construct entities
--- -N- F03/0141 More than one specific interface for a procedure


F03/0034 Comment.
Robert Corbett suggests noting the difference between IEEE_LOGB and
the definition of "logb" in 754-2008 (the 754 committee having decided
to change it from the 754-1985 version).  This would not make sense in
the context of a Fortran 2003 interp (since we have no time machine);
nor, since the normative reference in Fortran 2008 is also to
754-1985, is it necessary there.

F03/0039 NO vote.
The suggested edit is not valid Fortran.  Any of the following
responses would be acceptable.
(a)
ANSWER:
The HYPOT example in note 14.17 illustrates the use of the features
of this section to provide reliable software that is fast in the
uncomplicated case.  It is not intended to be the C "hypot" function.
{No DISCUSSION.}
EDIT:
None.
(b)
ANSWER:
The HYPOT example in note 14.17 illustrates the use of the features
of this section to provide reliable software that is fast in the
uncomplicated case.  It is not intended to be the C "hypot" function.
DISCUSSION:
In fact, if either X or Y is a NaN, the first executable statement
will set HYPOT to a NaN without signaling an exception. The slower
code in the IF construct will therefore not be executed and a NaN
will be returned, which is consistent with the way NaNs are handled
by intrinsic operators, see paragraph 3 of section 6.2 of the
IEEE International Standard.
EDIT:
[388] After the "Try a fast algorithm first" comment, insert
  "! (If either X or Y is a NaN, this will set HYPOT to a NaN
   !  without signaling an exception.)"

F03/0063 NO vote.
As Bill Long pointed out, this version leaves junk in the standard that
thinks procedure pointers are allowed in COMMON blocks.  Therefore the
edits need to include
  [100:12-15] Delete "A procedure ... type parameters.".
As for Bill's other suggestion re the definition of storage sequence,
I don't think that matters since procedure pointers should not appear
therein.  OTOH, I have no objection to his suggested
  [416:23-24] "pointer"->"data pointer"
and this is a certainly a good idea for F2008.
I also agree with David Muxworthy's suggested change for the [98:21]
edit (insert comma after allocatable).

F03/0090 NO vote.
Technical objection:
1. There is no edit that prohibits an array contructor ac-value from
   being unlimited polymorphic (i.e. CLASS(*)); we should state this
   directly, not make people infer it from more difficult rules.
   Proposed fix:
     [67:19+] Insert new constraint
       "An <ac-value> shall not be unlimited polymorphic.".
Philosophical maunderings:
2. The answer impedes any future extension to allow polymorphic array
   constructors.  The obvious way to prevent closing the door to
   future extension is to prohibit an ac-value from being polymorphic.
   Possible change:
     [67:19+] Insert different new constraint instead
       "An <ac-value> shall not be polymorphic.".
3. The situation in point 2 above is a bit unfriendly.  Furthermore
   the comment that a function can be used to safely construct a
   polymorphic array is slightly naive: this requires separate
   processing for each potential dynamic type, so does not scale well.
   Possible response:
     Change the answer to allow polymorphic array constructors.

F03/0129 Comment.
John Reid writes:
>The third edit should be
>[396:5-7] Replace "; if ... one." with
>   ".  If the type is character, it is interoperable if and only if
>   the value of its length type parameter is one."
> Reason: It makes no sense to talk about the length type parameter
>         being interoperable.
Au contraire, it makes reasonable sense given
  "A Fortran intrinsic type with particular type parameter values
   is interoperable ..."
In any case the existing edit is superior, the suggested edit is
contradicted by the existence of CHARACTER with KIND/=C_CHAR.

F03/0133 NO vote.
This interp should be marked as a duplicate of interp F03/0046, which
in fact it is.  F03/0046 is currently failing as a result of
inconsistencies between it and F03/0053.  I think it would be best to
consider the original (0046 and 0053) together and not just to pass
one of them.  I apologise for raising this duplicate.

F03/0135 Comment.
I agree with David Muxworthy's change to the edit for [276:36+]
("the"->"that").  I agree with John Reid that the word "of" should be
added after "scoping unit is" in both edits.

F03/0138 Comment.
Reinold Bader asks
  why is having "X" on the right hand side of a procedure pointer
  assignment considered insufficient
Mostly because "p => x" does not give any visual clue that X is a
procedure.  Partly also because it would be problematic if we added
user-defined pointer assignment.  Procedure pointers (and their
targets) are modelled closely on dummy procedures (and their
corresponding actual procedures); those require an explicit EXTERNAL
attribute, but we felt that in the case of a procedure reference
(e.g. "CALL x") in the scoping unit it was sufficiently obvious and
unlikely to be problematic that we could diverge from the argument
requirements in that case.  Finally, it was not our intent to require
compiler (and user) inference of procedureness of being a target in
the pointer assignment case; omission of wording here was accidental.
Post-finally, should we ever allow user-defined pointer assignment, we
definitely would not want inference as that would clash with generic
resolution.

F03/0139 Comment.
The word "which" in the edit for [407:21-22] is correct.

F03/0141 NO vote.
On reflection, I agree with Reinhold Bader's comment that the edit
does not really make sense.  Here is an alternative edit:
[260:2] After "scoping unit" insert
  ", except that if the interface is accessed by use association,
   there may be more than one local name for the procedure".
{Yes, here we really do want "may", because we are giving permission.}
If it's not otherwise clear, we might want to also say
  "If a procedure is accessed by use association, each access shall be
   to the same procedure declaration or definition."

===END===