(j3.2006) J3 09-155 interp letter ballot #18 due 23-Mar-2009

Malcolm Cohen malcolm
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
                      defined assignments
-Y-  ---  F03/0119  Elemental procedures and deferred length character
-Y-  ---  F03/0122  When do objects of sequence derived type have the
                      same type?
-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.

Also consider

     MODULE m3
       PROCEDURE(s),POINTER :: sptr
       SUBROUTINE s(p)
         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

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 mailing list