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

[Jim Xia]

The following Fortran interpretations are being balloted:

Yes  No   Number    Title

---  -N-  F03/0063  Procedure pointers in BLOCK DATA program
                     units
---  -N-  F03/0064  Recursive declaration of procedure interfaces
-Y-  ---  F03/0065  Relational equivalence
---  -N-  F03/0071  Subroutine/function ambiguity in generics

-Y-  ---  F03/0112  Attributes allowed for dummy arguments in
                     defined assignments
-C-  ---  F03/0119  Elemental procedures and deferred length character
                     components
-Y-  ---  F03/0122  When do objects of sequence derived type have the
                     same type?
---  -N-  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
-C-  ---  F03/0128  Subobjects in namelist output
-C-  ---  F03/0129  C_LOC of character substrings



----------------------------------------------------------------------
NO comment on F03/0063

I agree with Bill that the edits need to include fixes to C587 and C590.
----------------------------------------------------------------------

----------------------------------------------------------------------
NO comment on F03/0064

The edits do not apply to example 1 and 2 in the extended discussion.
In both examples, module procedures are used.  The term <interface-body>
is not applicable to them as indicated by Note 12.3 on page 258

"An interface body cannot be used to describe the interface of an internal 
procedure, a module
procedure, or an intrinsic procedure because the interfaces of such 
procedures are already explicit."

Furthermore the discussion on example 2 is more confusing than useful 
because it
refers to IMPORT statement.  I can not see how the IMPORT statement is 
relevant
to this example.
----------------------------------------------------------------------

----------------------------------------------------------------------
NO comment on F03/0071

The reason for my NO vote is exactly the same as I stated in J3 letter 
ballot #17 (08-259).
I believe it is a poor decision to assume the user *must have meant* ff to 
be a function name in resolving
the generic name Q.  Asking programmers to explicitly declare the type, or 
better the interface of
procedure ff is helping them avoid writing sloppy programs.
----------------------------------------------------------------------


----------------------------------------------------------------------
YES comment on F03/0119

The example3 contains an error in the derived type definition of t1:
  TYPE t1(n)
    INTEGER,LENGTH :: n
...

should be
  TYPE t1(n)
    INTEGER,LEN :: n
...
----------------------------------------------------------------------


----------------------------------------------------------------------
NO comment on F03/0125

I disagree with the edits to make return result of EXTENDS_TYPE_OF as
processor dependent when dynamic type of either A or MOLD is not 
extensible.
It should be clear that in such case the return value of EXTENDS_TYPE_OF 
is false
because the concept of type extension is only applicable to extensible 
types.
----------------------------------------------------------------------


----------------------------------------------------------------------
YES comment on F03/0128

I agree with Bill that the edits should refer to [247:27].
----------------------------------------------------------------------



----------------------------------------------------------------------
YES comment on F03/0129

In the first edit, [395:8(16.1.2.5)] should be [395:8(15.1.2.5)].

In the fourth edit at [399:2-2(15.2.4p1)], it says
                  Change "and" to a comma,
I assume "and" is referring to the 2nd and in this sentence.  Also in this
edit, can we be clear that the initialization expression for length must
evaluate to one (1).  It takes the combination of edits at [396:5-7] and
[399:2-2(15.2.4p1)] to deduce this.  The current edit may result in wrong 
assumption
by users that a variable declared such as character(2) is also 
interoperable with a C entity.

The last edit at [399:7-8(15.2.5)] has exactly the same problem as to that 
in the previous edit.
----------------------------------------------------------------------




Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20090305/c3dd3d1b/attachment.html