<br><font size=2 face="sans-serif">The following Fortran interpretations
are being balloted:</font>
<br>
<br><font size=2 face="sans-serif">Yes No Number Title</font>
<br>
<br><font size=2 face="sans-serif">--- -N- F03/0063 Procedure
pointers in BLOCK DATA program</font>
<br><font size=2 face="sans-serif">
units</font>
<br><font size=2 face="sans-serif">--- -N- F03/0064 Recursive
declaration of procedure interfaces</font>
<br><font size=2 face="sans-serif">-Y- --- F03/0065 Relational
equivalence</font>
<br><font size=2 face="sans-serif">--- -N- F03/0071 Subroutine/function
ambiguity in generics</font>
<br>
<br><font size=2 face="sans-serif">-Y- --- F03/0112 Attributes
allowed for dummy arguments in</font>
<br><font size=2 face="sans-serif">
defined assignments</font>
<br><font size=2 face="sans-serif">-C- --- F03/0119 Elemental
procedures and deferred length character</font>
<br><font size=2 face="sans-serif">
components</font>
<br><font size=2 face="sans-serif">-Y- --- F03/0122 When
do objects of sequence derived type have the</font>
<br><font size=2 face="sans-serif">
same type?</font>
<br><font size=2 face="sans-serif">--- -N- F03/0125 Definitions
of EXTENDS_TYPE_OF and SAME_TYPE_AS</font>
<br><font size=2 face="sans-serif">-Y- --- F03/0126 References
to VOLATILE variables in pure procedures</font>
<br><font size=2 face="sans-serif">-Y- --- F03/0127 Duration
of procedure execution</font>
<br><font size=2 face="sans-serif">-C- --- F03/0128 Subobjects
in namelist output</font>
<br><font size=2 face="sans-serif">-C- --- F03/0129 C_LOC
of character substrings</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">NO comment on F03/0063</font>
<br>
<br><font size=2 face="sans-serif">I agree with Bill that the edits need
to include fixes to C587 and C590.</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">NO comment on F03/0064</font>
<br>
<br><font size=2 face="sans-serif">The edits do not apply to example 1
and 2 in the extended discussion.</font>
<br><font size=2 face="sans-serif">In both examples, module procedures
are used. The term <interface-body></font>
<br><font size=2 face="sans-serif">is not applicable to them as indicated
by Note 12.3 on page 258</font>
<br>
<br><font size=2 face="sans-serif">"An interface body cannot be used
to describe the interface of an internal procedure, a module</font>
<br><font size=2 face="sans-serif">procedure, or an intrinsic procedure
because the interfaces of such procedures are already explicit."</font>
<br>
<br><font size=2 face="sans-serif">Furthermore the discussion on example
2 is more confusing than useful because it</font>
<br><font size=2 face="sans-serif">refers to IMPORT statement. I
can not see how the IMPORT statement is relevant</font>
<br><font size=2 face="sans-serif">to this example.</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">NO comment on F03/0071</font>
<br>
<br><font size=2 face="sans-serif">The reason for my NO vote is exactly
the same as I stated in J3 letter ballot #17 (08-259).</font>
<br><font size=2 face="sans-serif">I believe it is a poor decision to assume
the user *must have meant* ff to be a function name in resolving</font>
<br><font size=2 face="sans-serif">the generic name Q. Asking programmers
to explicitly declare the type, or better the interface of</font>
<br><font size=2 face="sans-serif">procedure ff is helping them avoid writing
sloppy programs.</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">YES comment on F03/0119</font>
<br>
<br><font size=2 face="sans-serif">The example3 contains an error in the
derived type definition of t1:</font>
<br><font size=2 face="sans-serif"> TYPE t1(n)</font>
<br><font size=2 face="sans-serif"> INTEGER,LENGTH :: n</font>
<br><font size=2 face="sans-serif">...</font>
<br>
<br><font size=2 face="sans-serif">should be</font>
<br><font size=2 face="sans-serif"> TYPE t1(n)</font>
<br><font size=2 face="sans-serif"> INTEGER,LEN :: n</font>
<br><font size=2 face="sans-serif">...</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">NO comment on F03/0125</font>
<br>
<br><font size=2 face="sans-serif">I disagree with the edits to make return
result of EXTENDS_TYPE_OF as</font>
<br><font size=2 face="sans-serif">processor dependent when dynamic type
of either A or MOLD is not extensible.</font>
<br><font size=2 face="sans-serif">It should be clear that in such case
the return value of EXTENDS_TYPE_OF is false</font>
<br><font size=2 face="sans-serif">because the concept of type extension
is only applicable to extensible types.</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">YES comment on F03/0128</font>
<br>
<br><font size=2 face="sans-serif">I agree with Bill that the edits should
refer to [247:27].</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">YES comment on F03/0129</font>
<br>
<br><font size=2 face="sans-serif">In the first edit, [395:8(16.1.2.5)]
should be [395:8(15.1.2.5)].</font>
<br>
<br><font size=2 face="sans-serif">In the fourth edit at [399:2-2(15.2.4p1)],
it says</font>
<br><font size=2 face="sans-serif">
Change "and" to a comma,</font>
<br><font size=2 face="sans-serif">I assume "and" is referring
to the 2nd and in this sentence. Also in this</font>
<br><font size=2 face="sans-serif">edit, can we be clear that the initialization
expression for length must</font>
<br><font size=2 face="sans-serif">evaluate to one (1). It takes
the combination of edits at [396:5-7] and</font>
<br><font size=2 face="sans-serif">[399:2-2(15.2.4p1)] to deduce this.
The current edit may result in wrong assumption</font>
<br><font size=2 face="sans-serif">by users that a variable declared such
as character(2) is also interoperable with a C entity.</font>
<br>
<br><font size=2 face="sans-serif">The last edit at [399:7-8(15.2.5)] has
exactly the same problem as to that in the previous edit.</font>
<br><font size=2 face="sans-serif">----------------------------------------------------------------------</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Jim Xia<br>
<br>
XL Fortran Compiler Test<br>
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7<br>
Phone (905) 413-3444 Tie-line 313-3444<br>
email: jimxia@ca.ibm.com<br>
D2/YF7/8200 /MKM</font>