(j3.2006) (SC22WG5.4147) Urgent: letter ballot on interps
Bill Long
longb
Tue Feb 9 19:46:36 EST 2010
Ballot vote from Bill Long, Cray Inc.
WG5 letter ballot 7 on Fortran 2003 interpretations
John Reid, 1 February 2010
The following Fortran 2003 interpretations are being balloted:
Yes No Number Title
-Y- --- F95/0098 Are dummy functions returning assumed-length character
legal?
-Y- --- F03/0022 Coexistence of IEEE and non-IEEE kinds
-Y- --- F03/0024 DEALLOCATE and array pointers
-C- --- F03/0034 IEEE_LOGB()
-C- --- F03/0039 HYPOT()
-C- --- F03/0063 Procedure pointers in BLOCK DATA program units
-Y- --- F03/0071 Subroutine/function ambiguity in generics
-Y- --- F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence
-C- --- F03/0090 Polymorphic array constructors
-Y- --- F03/0112 Attributes allowed for dummy arguments in defined
assignments
-Y- --- F03/0119 Elemental procedures and deferred length character
components
-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
-Y- --- F03/0129 C_LOC of character substrings
-Y- --- F03/0130 Elemental specific intrinsic procedure characteristics
-Y- --- F03/0131 SAVE attribute and EQUIVALENCE
-Y- --- F03/0132 Unformatted i/o and private components
-Y- --- 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
-Y- --- F03/0138 External <procedure-name> as <proc-target>
-Y- --- F03/0139 Functions returning procedure pointers
-Y- --- F03/0140 Type of nested construct entities
-Y- --- F03/0141 More than one specific interface for a procedure
--------------------
Comment for F03/0034 - IEEE_LOGB()
I agree with David's comment that the wording of the edits should be
inverted to be "If X is ... and IEEE_SUPPORT_... is true, ..."
--------------------
Comment for F03/0039 - HYPOT()
Nick's comments about the IEEE nonconformance of the proposed change
might be considered for 13.7.69 "HYPOT (X, Y)" in F08
09-007r3[353:18-27]. The HYPOT defined in Note 14.7 is not really
claimed to be the official IEEE HYPOT, but rather is a contrivance to
illustrate the setting and getting of IEEE flags.
I would argue that if we decide to include the suggested edit, it
defeats the current comment of "Try the fast algorithm first". With
this new code, the algorithm is no longer fast. The comment should be
deleted.
Further, instead of somewhat obscure
HYPOT = SQRT(-1.0)
why not be clear about the intent and write
HYPOT = IEEE_VALUE(X, IEEE_QUIET_NAN)
However, the initial sentence of the Discussion section notes that "if
either X or Y is a NaN, the [statement HYPOT = SQRT( X**2 + Y**2 ) ]
will set HYPOT to a NaN..." which is exactly what the inserted code
does. So the proposed edit adds no useful functionality and causes
the code to run slow. It seems better to not add the new code and,
instead, add a comment line in the code noting that a NaN argument
would result in a NaN result. It might also make Fred Tydeman happier
if the Note pointed out that the example is not an implementation of
the IEEE HYPOT function (at least it's not a valid one). I believe
that Fred (and maybe Nick) would be happy of the name of the function
were something other than HYPOT, to avoid confusion with the IEEE
HYPOT function.
---------------------
Comments for F03/0063 - Procedure pointers in BLOCK DATA program units
1) I agree with the comment of David that a comma should be inserted
after 'allocatable' in the edit instructions for the edit at [98:21].
2) In 5.5.2.3 "Common association" at [100:12-15] there are three
sentences beginning "A procedure pointer shall be storage associated
...." through the end of the paragraph. Should these three sentences
be deleted? Corresponding reference in 09-007r3 is [115:35-38] 5.7.2.4
"Common association", paragraph 6.
3) It seems like in item (8) in the list of 16.4.3.1."Storage
sequence", [416:23-24] "pointer" should be "data pointer". If
procedure pointers can be in a storage sequence, then a list item (9)
should be created for them, and text similar to [100:12-15] might be
used. In 09-007r3, [451:33-36] in 16.5.3.2 "Storage sequence".
--------------------
Comment for F03/0090 - Polymorphic array constructors
Should the edit for [68:9] also be applied to [68:11]? The <type-spec>
is effectively a declaration of the type of the constructor, so saying
"declared type" seems clearer. It also results in more parallel
language - two paragraphs saying how the declared type is determined,
followed by a paragraph saying that the dynamic type is the same as
the declared type.
--------------------
Comment for F03/0135 - Interaction between RESULT ....
I agree with David that the "the" in the first edit should be "that".
In addition, the "(a2)" in the first edit would normally be denoted
"(a1)" (even though the actual numbering is automated). It would save
people looking for the missing a1.
-----------------End of
Ballot----------------------------------------------------------
John Reid wrote:
> WG5,
>
> There are now 28 interpretations ready for WG5 letter vote. This time, I am
> making it a 14-day ballot in order that it is complete before the meeting in Las
> Vegas starts. I hope this is acceptable to everyone.
>
> With best wishes,
>
> John Reid.
>
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3
mailing list