From jls@uxb.liv.ac.uk Mon Feb 15 16:31:11 1993 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA10301 (5.65c8/IDA-1.4.4j for ); Mon, 15 Feb 1993 17:31:47 +0100 Received: from mail.liv.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Mon, 15 Feb 93 16:31:04 GMT Received: from uxb.liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <08550-0@mailhub.liverpool.ac.uk>; Mon, 15 Feb 1993 16:31:42 +0000 From: jls Message-Id: <13097.9302151631@uxb.liv.ac.uk > Subject: CCI ballot To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Mon, 15 Feb 93 16:31:11 GMT X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 To: ISO/IEC JTC1/SC22/WG5 From: Lawrie Schonfelder Subject: Comments and ballot on maintenance items The titles of the 70 items are listed below, "Y" indicates the "Yes" column (without comments), "wc" next to "Y" represents the "Yes-with-comments" column, and "N" indicates the "No" column. Comments or reasons may be inserted after each item. |Y|wc N N865 Item |x|_| |_| 000000 Minor edits and corrections to ISO/IEC 1539:1991 (E) |x|_| |_| 000001 Equivalence of Expression Evaluations |x|_| |_| 000002 Default Main Program Name |x|_| |_| 000003 Preconnected Units and UNIT=* |x|_| |_| 000005 Namelist Output of Zero Length Character Strings |_|_| |x| 000006 Procedure Specifications in a Scoping Unit |x|_| |_| 000009 Generic Interfaces with the Same Name in a Program |x|_| |_| 000010 Generic Interfaces with the Same Name in a Scoping Unit |_|_| |x| 000013 Implicit Environment of an Interface Block |x|_| |_| 000014 Interface for Character Function with a Variable Length Result |x|_| |_| 000015 Error in Fourth Constraint for R429 |x|_| |_| 000016 Character Length Specification |x|_| |_| 000017 Creation of Entities by Local Names in rename-list |x|_| |_| 000018 Valid Characters Indicating Fixed Form Statement Continuation |x|_| |_| 000019 Correctness of Last Example in Section 4.5 |_|x| |_| 000020 References to the Same Derived Type by Different Names |_|x| |_| 000021 References to Different Derived Types with the Same Name |_|x| |_| 000022 Use of Derived Type Name in Host Scoping Unit |x|_| |_| 000024 IMPLICIT NONE and the Type of an Internal Procedure Result |x|_| |_| 000025 Resolution of Internal Procedure References |x|_| |_| 000026 Bounds of Array Expressions |_|_| |x| 000031 Overloaded Implied-DO Variable Names |x|_| |_| 000032 Implicit Declaration of a Derived Type |x|_| |_| 000036 Pointer to an Assumed-size Array |_|_| |x| 000037 Use of Array Sections in Pointer Assignment Statements |_|_| |x| 000038 Same Interface Body in Multiple Generic Interface Blocks |x|_| |_| 000039 Association of a Pointer Actual Argument with a Dummy Argument |x|_| |_| 000040 Allocation of Arrays of Pointers |x|_| |_| 000042 KIND parameter value |x|_| |_| 000043 List-directed character input |x|_| |_| 000044 END Statement and Fixed Form Source |x|_| |_| 000045 Array Intrinsics with Arrays of Derived-type Arguments |x|_| |_| 000046 RESULT clause for RECURSIVE functions |x|_| |_| 000047 Automatic data object in initialization expressions |x|_| |_| 000048 Pointer-valued statement functions |x|_| |_| 000050 Repeat counts on edit descriptors |x|_| |_| 000051 On Unambiguous generic procedure references |x|_| |_| 000052 Expressions in Statement Function Definitions |x|_| |_| 000053 Optional Intrinsic Function Arguments |x|_| |_| 000055 Characteristics of character function results |x|_| |_| 000056 TRANSFER intrinsic function description |_|_| |x| 000057 Prohibition against multiple explicit specific interfaces |_|x| |_| 000059 SEQUENCE derived type and component bounds |x|_| |_| 000060 Statement function argument references |x|_| |_| 000061 G edit descriptor with _d_ = 0 |x|_| |_| 000062 Statement function constraints |x|_| |_| 000063 Interfaces and dummy procedure arguments |x|_| |_| 000064 SPACING result for 0.0 |x|_| |_| 000065 Block and Nonblock DO Construct |x|_| |_| 000066 Declaration of FUNCTION type |x|_| |_| 000067 Output of negative signed zero |x|_| |_| 000068 Pointer association status |x|_| |_| 000069 I/O implied DO variable |x|_| |_| 000072 Missing constraint for SIZE= |x|_| |_| 000074 Meaning of "referenced" in 11.3.2 |_|_| |x| 000078 Intrinsic functions in MODULE specification statements |x|_| |_| 000080 Vector subscripts in masked array assignment statements |x|_| |_| 000084 Change masked array assignment constraint to prose |x|_| |_| 000085 Nondefault Integer Data Type for UNIT=, ... Specifiers |x|_| |_| 000094 Functions in WRITE statement implied-DO loops |x|_| |_| 000095 Functions in IOLENGTH implied-DO loops |x|_| |_| 000098 KIND param and list directed I/O |x|_| |_| 000103 Statement Function with unreferenced dummy argument |x|_| |_| 000104 rounding formatted output |x|_| |_| 000107 USE renaming of generic and specific interfaces |x|_| |_| 000109 Intrinsic Function ASSOCIATED |x|_| |_| 000110 Named Constant Shape Specification |x|_| |_| 000115 Multiple dummy arguments |_|_| |x| 000118 Named constructs and host association |x|_| |_| 000119 Rank of assumed-shape array |x|_| |_| 000120 PRESENT intrinsic and host association General: I view with concern the size of this document and the idea of publishing it as-is as a technical corrigendum. Many of the individual items appear to be often subtle and minor variations on a theme. I cant help wondering if it might not be better for all these to be collected together and a single clarification and/or correction produced. Otherwise I fear we are in danger of producing a CCI document that is comparable in size to the original standard. This I would have thought highly undesirable and not a true representation of the quality of the original document. As most of the CCI questions are being generated within the committee and not from the outside users I fear the size of the document is an all too elequent demonstration of the ingenuity of the committee members in dreaming up obscure questions. The upshot of this concern is that I think we should take a long hard and critical look at the items we agree, not for technical content but with a view to deciding if there genuinely is a need to publish the CCI item. The individual submitting the query should be given the answer but publication to the whole world should be done only where there is a real danger of erroneous implementation. Comments with specific YES votes: (20) All of these questions are variations on a similar theme and (21) should probably be covered in a single item. Incidentally, they (22) also demonstrate rather well how confusing SEQUENCE derived types can be. The moral of the story is dont use them non-sequence types are very much easier to handle and are more likely to be optimisable. (59) This again a case of sequence structures proving to be very confusing. This must be one of very few places where conformace demands identity of bounds as well as shape. Reasons for NO votes: (5) I do not believe that duplication of specification when the attribute specified is identical and checkable as such is undesirable. On the contrary, I believe the perpetuation of this restriction was and is a bad idea. This is particularly true for interfaces. There are very good software engineering reasons for the deliberate duplication of interface specification. Basically we already have duplicate interfaces. The interface of an external procedure is declared in an interface block and in the procedure that defines it. Unfortunately there is no way of checking that these agree. However, we illogically bar duplicate declaration in circumstances where the processor could check that the declarations were identical, viz module and internal procedures, and now we are proposing to tighten this restriction further. There are very good user reasons for allowing duplication. If duplication is permitted the source of a module before the CONTAINS can become a very good basis for the reference documentation of a module; the MODULE PROCEDURE statement is of no human interest at all. When writing a large module the procedure interfaces, particularly those determining the overload resolution structure is the primary top-level design issue. The coding of the specific procedure definitions is at a different level of successive refinement in a top-down development process. The full details of the interface are, however, needed in both contexts. For maintenance purposes it is then critical that the duplicate interfaces are checked. Having the interface in only one place, regardless of which it is is not conducive to good design and development processes nor does it help implementation. As a result I have voted NO on all items that have applied additional restrictions on Fortran 90 making duplication less possible. I believe the correction to the existing irregularity of definition in this area should be the relaxation of restriction not the tightening of it. In this particular case I believe that a procedure that is explicitly declared by an interface body and is hence also declared as an external procedure should also be allowed in an EXTERNAL statement. In a sence the interface body implicitly declares the procedure to be external and the EXTERNAL statement merely confirms this. (13) I believe this item is factually incorrect. The standard is intentionally correct as written. This was a late change made because of comment made during balloting. Of this I am sure since I was one of the commentors involved. The implicit mapping rules of the host were meant to apply to all contained scoping units unless the contained scoping unit redefines the mapping explicitly. This was most definitely meant to apply also to interface bodies as well as internal procedures, etc. The reason for this is that in many cases the writer of the program does not have access to the source of the external procedure. He or she will often have a precompiled version and the documentation that describes the procedure and its arguments. The user therefore does not know the implicit mapping of the external procedure. The user, however, always knows the mapping he or she is using to write the host program. If a user employs the default implicit mappings, which is by far the most likely, no surprises will result. If on the otherhand the user does make an explicit change to the mapping it will be a very great source of surprise if in the declaration of a procedure interface the mapping suddenly reverts to the default. In particular this will greatly upset the careful programmer who deliberately turns off implicit declaration by the use of IMPLICIT NONE in the host only to have it turn on again in each interface body. Consider, PROGRAM MAIN IMPLICIT NONE ... INTERFACE FUNCTION FUN(A1,I0) INTEGER :: AI,IO,FUN ENDFUNCTION FUN ENDINTERFACE ... The writer of such a program is going to be both surprised and not a little irritated to find that his program compiles but has precisely the sort of errors he thought he was protecting himself against. (31) I do not believe we should be making changes that make type- names more a part of the same class as variables. I think this was a mistake in the first place and we should rather be correcting this by defining type-names to be a separate class. This is important for the future improvement of Fortran's OOP and data-abstraction capabilities. Should not the solution to this issue be that implied do indicies in specification statements like data have the scope of their implied do and inside the do mask any object of the same name in the host. (37) I do not believe it was the intent to allow assumed-size arrays or any section of an assumed-size array to be a pointer target. I also find it a serious irregularity to have an object that cannot itself be a pointer target but where all subobjects can be. This anomaly should be corrected by a constraint that forbids the TARGET attribute for assumed-size arrays. (38) As indicated above this is I believe compounding a deficiency in Fortran 90. Provided the specific interfaces are identical, they specify the same characteristics for the procedure and the same names for the dummy arguments, there is no ambiguity problem and this is functionality that would be useful in fact is quite likely to occur. Consider a module that defines facilities for scalars, vectors and matricies. It might well have a generic interface for a mathemetical function defined for all three types. Another module might define facilities for reals, complex values and quarternions. The same mathematical function could well be defined by a generic set in this module. The scalar and real case in each module would be implemented by the same external function. If both modules were to be used in the same program we have the duplicate declaration. However, this should not be a problem. It would only become one as a result of this "clarification". (57) Again this clarifies and makes more explicit the unfortunate feature of Fortran 90 which tries to prohibit duplication of interface declaration. This is the wrong fix moving in the wrong direction. All of these questions should be handled by an amendment, or a fix in the next revision, which allows the duplicate declaration of identical interfaces. (78) It is not clear to me that the use of the intrinsic function IABS in the module causes it to be made accessible in the using program by USE association. There is no ambiguity. When the module is compiled the intrinsic function is invoked to determine the size of the array, but when the program user is run the specific intrinsic function is masked by the declaration of IABS as a variable. The only thing the using program "sees" is the size of the array not how this was calculated. This appears to be similar to the situation where the intrinsic function was employed within the body of a module procedure. That also would not constitute a use which makes the intrinsic function visible. However, the case where the module contains explicitly a declaration of IABS is making the name IABS visible with the attribute of being an intrinsic function. In this case the using program is accessing IABS by use association and so a local declaration would become illegal. (118) Construct names are always sytactically distinguished from any variable name, etc. which happens to be the same. Hence, I cannot see any reason for trying to place construct names in the same class as variables, etc. In fact it would be desirable for language to recognise the fact that the scope of a construct name is that of the construct not even the program unit. If this were done it would become possible for simmilar loop structures which are often repeated with minor variations to reuse the same construct names. For example, it is often desirable to write something like, outer: DO ... ... EXIT outer ... ENDDO outer ... outer: DO ... ... EXIT outer ... ENDDO outer The current rule which means that different names have to be used for each loop does not help clarity and it complicates the development. The second set of loops is produced by editing a copyn of the first. The changing of construct name adds unnecessarily to the work of doing this. JLS/Feb'93 -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk