ISO/IEC JTC1/SC22/WG5 - N243 Note From : L.G.J. ter Haar To : TC97/SC22/WGS meeting Liverpool 3-7 August 1987 X3J3 meeting Liverpool 10-14 August 1987 Re : The Dutch standpoint on Fortran 8X S8.l04 l. INTRODUCTION In the last balloting period the Dutch Fortran Committee has not taken the opportunity to vote as we did not have sufficient time to prepare the comments. The committee would have voted yes with comments, if only for the reason that we think the revision of Fortran77 is badly needed. First of all we wish to congratulate the X3J3 committee with what is accomplished thus far. Looking back at the old working documents. we realise that the quality of the language and the document has increased dramatically (perhaps this is a reason for not hurrying matters too much). Many of our original misgivings (reflected a.o. in our comments prepared for the Bonn meeting 1985), are remedied in the current document. Nevertheless we still have our doubts about certain parts of the draft proposal. Therefore we have produced three proposals which we request to be voted upon at the WG5 meeting in Liverpool and to be taken to the subsequent X3J3 meeting, and a chapter containing some miscellaneous comments and suggestions. Quite obvious, if these thoughts do get sufficient support in WG5, we do not oppose any proposals based on these comments. Our guiding principles were and still are: - Fortran must be a easily portable language, providing means of writing reliable, long life software. As regards reliability we welcome the concept of deprecation although some horrible features may never disappear. We hope that future compilers will have means to rub this in to programmers. - Fortran must be easy to learn and must appeal to the current user community, mostly found in mathematical and engineering disciplines. On the topic large vs complex we take the stand that additions to the language must be easily to comprehend and must give useful additional functionality. - Fortran must make efficient use of hardware. - Development of the language should follow closely the development of hardware and established software engineering principles. We feel that Fortran 8X is not yet a language for development of 'personal' applications. We are somewhat concerned with the choice of removed extensions. It seems that some of those have much requested functionality whereas on the other hand there is new syntax that does not add to the functionality at all. In this light our proposals l and 2 should be regarded as an attempt to diminish the size and complexity of the language without sacrificing its functionality. We want to remind that the language C is becoming rapidly a popular language, not because it is particularly good, but because it has the functionality required for modern hardware (personal computers). 2. PROPOSAL l. ACCURACY OF real_literal_constants. 2a. Add to paragraph 4.3.1.2 the following sentences: A real constant used in a parameter assignment of the form: param_name = real_literal_constant assumes the accuracy (and exponent_range) of that of param_name regardless its appearance. In all other cases the actual accuracy of a real_literal_constant is at least default real for constants having no exponent letter and declared precision implied by the exponent letter if present. Real_literal constants must not be passed as actual argument to a dummy argument of the type real with specified precision an exponent_range 2b. Delete EXPONENT LETTER statement and all associated syntax. 2.1 Rationale - EXPONENT LETTER is a clumsy piece of syntax nowhere known in any other language (???) - It is at least rather strange to call one letter (D) deprecated and all other letters good programming practice. - EXPONENT LETTER is insufficient. Consider the following example: -7 -7 f(x) = l.3*l0 if x < l.3*10 = l.7 if x > l.7 = x otherwise Write a precision independent function to accomplish this. A proposed solution is: FUNCTION f(x) REAL(*,*) x REAL(EFFECTIVE_PRECISION(X), EFFECTIVE_EXPONENT_RANGE(x)) f,c1,c2 C We would like to write REAL(*,*) x,f,c1,c2 C There can be no confusion to the meaning of this statement as the C standard requires that all (*,*) specifiers should apply to the same C actual accuracy and exponent range. PARAMETER (c1=l.3E-7, c2=l.7) f = MAX (c1, MIN(c2,x) ) END However the standard does not ensure more than default real precision for the constants represented by c1 and c2, although x and thus f may be double precision. The only alternative proposed by the standard seems to pass c1 and c2 as actual arguments, which we feel is absurd. we wish to stress that adoption of proposal 2a is sufficient to guarantee desired accuracy for real constants. It is also usable in current Fortran77 practice where by adopting this approach (and using generic intrinsics) the only change to be made to a subprogram to turn it from single precision to double is to add the statement: IMPLICIT DOUBLE PRECISION (A-H,O-Z) Perhaps there is a case to extend proposal 2a also to the DATA statement. 3. PROPOSAL 2. REDUCE SYNTAX ON SPECIFICATIONS. 3a Reduce attr_spec_list (R505) in the type specification to ALIAS and ALLOCATABLE only. Alternatively invent a statement for ALIAS and ALLOCATABLE and reduce this list to NIL. Another alternative is reducing the statements. 3b Reduce optional and multiple (i.e. different ways of writing same functionality) syntax as much as possible. 3.1 Rationale Multiple syntax gives rise to different personal styles of programming. For newly to be developed software this may not be too bad but it becomes an issue if these styles are mixed when programs have to be maintained. Equivalent syntax is unnecessary confusing for people wishing to learn and master the language. Consider the following equivalent syntax: R502 length_selector .EQV. R501 entity_decl_list R505 value_spec .EQV. PARAMETER or DATA statement '' access_spec .EQV. access_stmt '' ARRAY arrray_spec .EQV. entity_decl_list '' INTENT spec .EQV. intent_stmt '' OPTIONAL attribute.EQV. OPTIONAL statement '' RANGE attribute .EQV. RANGE statement '' SAVE attribute .EQV. SAVE statement An even more striking example is the following all accomplishing the same functionality: CHARACTER(LEN=10) A CHARACTER*l0 A !deprecated CHARACTER(l0) A CHARACTER*(l0) A !deprecated CHARACTER*l0 , A !deprecated CHARACTER*(l0) , A CHARACTER A*l0 ! We like this one most CHARACTER*(*) A*l0 !deprecated CHARACTER(LEN=*) A*10 ! and this list could easily be extended!!! The intent_stmt, the optional_stmt, the save_stmt and the access_stmt may be written with or without ::. WHY NOT CHOOSE FOR ONE OR THE OTHER??? Note: if object oriented programming is the reason for introducing attributes in object declarations, we claim that this is merely a stylistic argument, by far not comparable to the reasons for introducing closed control structures. We are happy in having modules and derived type as a means for implementing object oriented programming in Fortran, but the precise syntax is not really important. 4. PROPOSAL 3. ON DEPRECATED FEATURES. 4a. The standard shall not contain any examples using deprecated features unless specifically so stated in adjacent comments. Examples should clarify the functionality, if necessary supported by comments. 4.1 Justification In a few instances examples of syntax are given that are considered deprecated features. We find this at least strange. One should not promote usage of parts of the language which are elsewhere considered bad programming practice. The current draft proposal contains already many good examples. We think however that it still could be improved by adding commentary explaining the semantics. Suggestions for improvement are: - P3-4.L2l : this is bad programming, one should not insert a blank in any syntactical item, even though blank is insignificant. - The following lines in the document contain deprecated features: P5-4L32, P5-7L32, P5-l2Lll. P5-l3L45-47. P5-l8L35, P5-l9Lll, P5-l9L47-48, PP5-20L37-39, P11-6Ll5-18. We suggest to add the comment ! This is a deprecated feature. - P9-l5L33. Although this is an example of correct Fortran, it is certainly bad programming. We suggest to add the comment; ! This tricky programming is not recommended. The examples on INTERFACE and related syntax is insufficient. - Para ll.3.3.S Page 11-5 suggest the (nice) usage of modules for definition of interfaces. It gives an explanation how the subroutine LLS may be invoked. However we miss in the example the method of defining the same subroutine. We suggest to add: ' This module allows the subroutine LLS to be defined: USE LIBRARY_LLS ! now follow any further specification statements and action statements ! defining the subroutine LLS END SUBROUTINE LLS Question : is this correct syntax? Question : what is the method if MODULE_LLS defines interfaces of more than one subroutine e.g. LLS and LL51. How to use ONLY, PRIVATE and PUBLIC if at all? - Para l2.3.2.l Page l2-3. Question : How is INVERSE invoked? e.g. CALL INVERSE (AACT, FNACT) Question : How is FNACT defined?? What if the interface of FNACT is in conflict with the example interface of FN?? 5. MISCELLANEOUS COMMENTS AND SUGGESTIONS. 5.1 On the syntax for declared precision and range. We think the precision_selector definition (R507) is overly complex. We would prefer it to be: precision_selector = ( [ PRECISION = ] type_param_value, [ EXPONENT_RANGE = ] type_param__value ) This requires indeed that both values must be given, but apart from being a clearer definition it would obviate the need for the constraint of R417 page 4-6, Ll7-l8. REAL(l0,*) should be interpreted as at least ten digits accuracy and don't care about exponent range. In our view it is even safer to let programmers declare that they don't care about exponent range than having it implicitly defined (by REAL(l0) )! Questions: a. Are PRECISION and EXPONENT_RANGE qualified names??? (para 4.4.l,P4—7,4—8) b. Are the following derived type definitions incorrect??? TYPE STRING ( PRECISION ) INTEGER LENGTH CHARACTER (LEN=PRECISION) VALUE END TYPE STRING TYPE MATRIX (NPREC,NEXPR,ORDER) REAL (NPREC,NEXPR) A(ORDER,ORDER) END TYPE MATRIX If the answer to both questions is yes, we find this very un Fortran like! If so what is the reason? If the answer is no, then we think the text of 4.4.1 is incorrect. c. What about the type of e.g. ORDER which must be integer. Must this be separately defined in an INTEGER type statement? PLEASE CLARIFY 5.2 On free source form we suppose this has been discussed at length in X3J3. However we are still concerned about the non upward compatibility. Automatic conversion from fixed form to free form will result in quite different looking programs. As a matter of fact, position 6 has never been a real issue, but relaxation of position 72 is now very much welcomed. We have some suggestions for improvement. The first is using the first character instead of the last character as continuation character. The reason is that we all like to see well readable programs. Continued statements must stand out and they only do if continuation characters line up, which would at least be difficult if the last character has to be put in a lined up position. The second suggestion is to leave positions 1-6 as non statement positions. Here again the reason is readability. Statement label, if present should be easily seen. An additional advantage would be that existing Fortran77 programs could easily be converted to the new free source form. Although blank significant is taken out of the proposal for good reasons, we still would like to see some sort of deprecation. It would be nice if processors would be able to detect bad programming practices. 5.3 On File Handling and related I/O In the Bonn meeting we had a paragraph on the same subject. Our standpoint has unfortunately not changed since and we repeat it here for convenience QUOTE F77 brought a thrill to the Fortran user community. At last, we can do proper I/O in Fortran without having to bother about Job Control Language. The actual implementation in various processors brought a lot of disappointment amongst the users. The reasons for disappointment stem, in our opinion, from the fact that there are too many loopholes in the semantics of the language: - definitions of some terms in the F77 syntax are at least rather weak. e.g. syntactical meaning of the word EXIST and error condition. What confines an error in one processor may not even be a warning for another. - the list of specifiers for the OPEN statement is not sufficient. - the abundant occurrence of the word processor-dependent makes portability a fallacy in practice. We should like this situation to be remedied in the new F8X proposal. We have the following suggestions: - definition of a minimal list of error conditions that cover practical applications. - a minimal set of allowed unit numbers. - in general, avoidance of processor-dependent where possible. - a clear-cut definition of the word exist. A Fortran programmer is only interested in existence prior to opening and after closing of files. The questions he wants answered are: is the file ever made? (can I open this file with status is ‘OLD'?), and is this file available for writing?( can I open this file with status is ‘NEW’ or 'SCRATCH'?). These questions may even be conflicting for the processor, so there may be a need for two different specifiers. - there is a need for a file extent specifier in the OPEN statement. In many cases the required file extent is dependent on external input parameters and can only be calculated inside the program. Can we allow for dynamic main memory allocation and at the same time forbid dynamic allocation of external memory? UNQUOTE We want to make some specific points: - as long as processors are allowed to interpret the existence of a file to depend on the presence of a job control statement (hence outside Fortran), meaning the file exists if the statement is there otherwise it does not exist, inquiry for existence has no useful meaning! - If opening of files is only allowed if there is a job control statement for it, the OPEN statement has very little meaning. - If one cannot allocate an extent for external memory by means of an OPEN statement, this OPEN statement is almost useless for scratch files. - If processors keep taking their own action in case of input format errors regardless the presence of the IOSTAT specifier, this specifier is useless. 5.4 On special characters (3.l.4 P3-l) The special character [ may be replaced by (/ and 1 by /). Does this imply that processors are allowed to replace or even not allow for brackets? What is the sense of having these duplicate forms in the first place? 5.5 On ALIAS and RANGE Is the functionality of ALIAS and RANGE of such importance that it warrants such a difficult and large piece of syntax? The examples given for ALIAS show a few interesting applications (e.g. skew sections of arrays, which are more difficult to accomplish without it), but the examples for RANGE are not at all convincing. On the contrary, we feel that the example given in appendix C.S PC-3 is counterproductive in the sense that the first two statements (not using RANGE) reflect the mathematical meaning far more appropriate.