(j3.2006) (SC22WG5.4805) WG5 letter ballot 4 on Fortran 2008 interpretations

[Robert Corbett]

The following Fortran 2008 interpretations are being balloted:

Yes  No Number     Title

-Y-  ---  F08/0043   Executing a type-bound procedure on a coindexed
                       object
-C-  ---  F08/0048   Sequence association for coarrays
---  -N-  F08/0054   Requirements for needing an explicit interface
-Y-  ---  F08/0055   G editing for reals
---  -N-  F08/0056   Non-polymorphic ALLOCATE with polymorphic SOURCE=
-Y-  ---  F08/0057   Interoperability with empty types
---  -N-  F08/0058   ENTRY point RESULT variable
-Y-  ---  F08/0059   Auto-targetting requirements
-Y-  ---  F08/0060   Procedure pointer assignment with an EXTERNAL target
-Y-  ---  F08/0061   Description of the CONTIGUOUS attribute misworded?
-Y-  ---  F08/0062   Mixing default initialization with DATA
                       initialization
---  -N-  F08/0063   G editing to a narrow output field
-C-  ---  F08/0064   STATUS of GET_ENVIRONMENT_VARIABLE
-Y-  ---  F08/0065   Should certain procedures in intrinsic modules be
                       pure?
-Y-  ---  F08/0066   Are certain expressions with pointer initialization
                       constant?
-C-  ---  F08/0067   Passing arrays of extended type objects
-Y-  ---  F08/0068   Pointer association and extended type arrays
-Y-  ---  F08/0069   Which part of an effective argument becomes
                       undefined?
-Y-  ---  F08/0070   Finalization of INTENT(OUT) arguments
-Y-  ---  F08/0072   Final subroutines with corank
-Y-  ---  F08/0073   Polymorphic auto-targetting

-------------------------
F08/0048 C

While I see no problem with implementing the feature as described in
the proposed interpretation, I would agree to defer approval of the
interpretation until after further consideration of Malcolm's
objections.

-------------------------
F08/0054 N

I think that the proposed interpretation is a misinterpretation of
what was intended by paper 02-144.  As I have said before, I think
that the paper was sloppy in that it did not mean a procedure
reference when it used the term "referenced."  I think that by
"referenced," it meant any use other than a declaration.
Nonetheless, I think the difference between the proposed
interpretation and what I think was intended in the paper is
small enough that I would not vote "no" on this interpretation for
that reason.

The reason I am voting "no" on this interpretation is that the
proposed edits are incorrect.  The text of the relevant portion of
the standard is also erroneous.

I assume that the term "procedure identifier" is meant to include
operators and the names of procedures and procedure pointers.  The
problem is that a generic identifier appears to fall under this
definition.  A generic identifier does not have either implicit or
explicit interface.  I do not see how the proposed edits apply in
the case of a generic identifier.

As I thought about the issue, I convinced myself that the property
of having implicit or explicit interface should apply only to the
names of procedures and procedure pointers, and not to procedures
themselves.  Because of renaming, a single procedure can have more
than one name in a given scoping unit.  The properties of each name
might be different.  For example, a function F might be identified
by the names G and H in a scoping unit.  The names of the dummy
arguments of G and H might be different.

-------------------------
F08/0056 N

I continue to oppose this interpretation.  I think the functionality
it provides is too little to be worth the risk of misuse.  I have yet
to think of a case where I would want use the functionality provided.
I can easily imagine cases where the wrong variable is used in the
SOURCE= specifier and the error goes undetected.

-------------------------
F08/0058 N

I continue to believe that removal of this restriction in Fortran 90
was deliberate.  The restriction in FORTRAN 77 was intended to make
it easier to write one-pass compilers.  Many such restrictions were
removed in Fortran 90.  The restriction serves no purpose now.

The restriction in the FORTRAN 77 standard is in paragraph 2 of
Section 15.7.4.

-------------------------
F08/0063 N

This interpretation upends the meaning of item (5) in Clause 10.7.2.1.
A similar argument could be made against any application of item (5).

I am surprised anyone thinks that editing under an F4.5 edit
descriptor should be permitted to produce anything other than four
asterisks.  Under the proposed interpretation, I have no idea what
should be expected as a result of editing under an F4.4 edit
descriptor.

-------------------------
F08/0064 C

There should be no "their" in the sentence

     This relies on their being a difference between "no value" and
     "zero-length value".

-------------------------
F08/0067 C

I agree that the program should not be standard conforming, and I agree
that the edit provided ensures that it is not.  I do not agree with the
rationale given for the answer.  Whether the invocation of SUB2 in SUB1
does or does not require the shape of A depends on the argument passing
conventions used by the processor.  While all or almost all existing
Fortran processors use copy-in/copy-out to pass the array argument to
SUB2, the Fortran standard does not require a conforming processor to
use copy-in/copy-out.  Other argument passing conventions exist that do
not require making a copy in this case.  Those conventions do not
require the shape or size of A to be known.