(j3.2006) J3 09-155 interp letter ballot #18 due 23-Mar-2009
Mon Mar 23 05:33:43 EDT 2009
The following Fortran interpretations are being balloted:
Yes No Number Title
-C- --- F03/0063 Procedure pointers in BLOCK DATA program
-C- --- F03/0064 Recursive declaration of procedure interfaces
--- -N- F03/0065 Relational equivalence
-Y- --- F03/0071 Subroutine/function ambiguity in generics
-Y- --- F03/0112 Attributes allowed for dummy arguments in
-Y- --- F03/0119 Elemental procedures and deferred length character
-Y- --- F03/0122 When do objects of sequence derived type have the
-Y- --- F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS
-Y- --- F03/0126 References to VOLATILE variables in pure procedures
-Y- --- F03/0127 Duration of procedure execution
--- -N- F03/0128 Subobjects in namelist output
-Y- --- F03/0129 C_LOC of character substrings
COMMENT for F03/0063 YES vote.
I agree with Bill Long's suggestions.
COMMENT for F03/0064 YES vote.
The entire DISCUSSION section should be deleted as it is wrong.
The answer does not address Rob James examples;
these appear to continue to be problematic.
PROCEDURE(s),POINTER :: sptr
PROCEDURE(sptr) :: p
In the normal course of events one would like to allow
PROCEDURE(module-procedure-name),POINTER :: mpptr
since it is natural to want to provide a procedure pointer that
matches a module procedure, so we should not just take away the
ability to use a (later-defined) module procedure here.
Rob James' suggestion of
"The characteristics of a dummy procedure shall not depend on
the characteristics of the procedure or interface body in which
it is declared."
would seem to catch all these examples. Unfortunately it breaks
REAL(KIND=3) FUNCTION F(G) RESULT(R)
REAL(KIND(R)),EXTERNAL :: G
In any case, the dummy argument case is different (it's certainly
trickier) and especially since there is not an obvious fix I would
prefer us to fix the original problem as described in F03/0064
using the edit there, and discuss and debate how to solve the
dummy procedure case separately.
I thought about
"The <interface-name> shall be previously declared or be the name
of an accessible module procedure; if it is the name of a module
procedure either the module procedure shall be previously defined
or the PROCEDURE statement shall appear in the specification part
of the module."
which seems to fix Rob's examples but unfortunately not mine.
The DISCUSSION section plus my additional example should be used to
form a new interp request.
REASON for F03/0065 NO vote.
I agree with Bob Corbett that "mathematical" treatment of relationals
is inappropriate and unfriendly. We should require the right answer.
Processors with deficient hardware that cannot compare numbers without
subtraction are notably thin on the ground these days; pandering to
them serves no useful purpose.
Also, the "mathematical" answer is the wrong answer for IEEE NaNs.
REASON for F03/0128 NO vote.
The sentence being edited begins
"The name of each namelist group object list item is placed ...".
This is not ambiguous in any way. The namelist group object list
items are the named variables in the NAMELIST statement; see p95
R553 <namelist-group-object> <<is>> <variable-name>
There can be no question about this, regardless of what nonstandard
behaviour some vendor might or might not do.
This is a feature request, and what's more, one that makes a processor
that uses the feature not compliant with Fortran 90/95. In the
compatibility section we list the things that "may have a different
interpretation" for F77, so this ought to be there as well (that is
if we thought it was a good idea).
Oh, and the edit is way short of implementing the feature, since the
"designator" of a namelist group object list item is just its name.
More information about the J3