Minutes of the April 1995 meeting of SC22/WG5 (Fortran) Kikai-Shinko Kaikan Bldg., 3-5-8 Shiba Koen, Tokyo, Japan 17-21 April 1995 1 Opening of the Meeting At 9am the acting convenor, Miles Ellis, opened the meeting. 2 Welcome of the Delegates The host, Hideo Wada, welcomed the delegates and explained the local arrangements. 3 Remarks from the Acting Convenor The acting convenor noted that the objectives of the meeting are: to process draft CD N1094 producing instructions for X3J3 as to the changes required to determine whether a third Corrigendum to Fortran 90 should be produced to determine future processing procedures to determine whether a rationale section should be included in Fortran 95 to discuss future distribution methods for WG5 papers to determine necessary maintenance and update processing procedures for IS 1539-2. He further noted the revised processing timetable and the effect of the new JTC1 rules on the production of new and revised standards. 4 Adoption of the Agenda The preliminary agenda (N1063) was adopted with some minor revisions noted. 5 Appointments The following appointments were made for this meeting: Recording Secretary Malcolm Cohen Librarian Tom Lahey Drafting CommitteeDavid Muxworthy (chair), Hideo Wada, Jerry Wagener, Wolfgang Walter. 6 Approval of the Minutes of the Edinburgh Meeting (Roth) The minutes of the Edinburgh meeting (N1061) were formally adopted (Muxworthy/Wagener). 7 National Activity Reports (Heads of Delegations) National Activity Reports were presented for Germany, Japan (N1105), UK (N1108) and USA (N1109). Lawrie Schonfelder noted that there was a draft version of 1539-2, identical to the standard except for the addition of line numbers, available in PostScript and HTML on WWW. Jerry Wagener noted that the paper size problem will be addressed in consultation with the editor Richard Maine; the CD will be produced either in A4 only or in A4 and 8.5 x 11. 8 Status of the Edinburgh Resolutions (X3J3 Report) Paper N1107 was presented. 9 Reports from Study Groups for Fortran 2000 Directions No reports had been received by the acting convenor by the time specified in resolution E16 for the Object-oriented and Interoperability Study Groups to report. No report was expected yet from the ISO 9000 Study Group until its reporting date (E8) at the end of August. Jamie Shiers reported that he had received so little response from his initial posting on object-oriented Fortran requirements that he had been unable to produce any report. Lawrie Schonfelder suggested that more concrete proposals should be circulated in order to elicit responses, rather than just a position paper. It was noted that although a draft report from the Interoperability Study Group had been circulated on the email reflector, this occurred after the deadline and no consensus had yet emerged from the discussion. 10 Development beyond Fortran 95 (N1104) Miles Ellis introduced a paper proposing the use of Type 2 Technical Reports as a means of creating a formal specification of the syntax and semantics of a limited number (2 or 3) of new features which had not made it into Fortran 95, but were felt to be too important to leave until Fortran 2000. He emphasised that the object would be to undertake not to change the syntax or semantics when the feature was incorporated into the next revision of the Standard unless experience in the implementation and use of the feature(s) had shown that a change was required. In this way, he hoped, implementors would feel able to implement these features ahead of formal standardisation. Lawrie Schonfelder: There is no reduction in balloting time or official processing; we only save our own time. Tom Lahey: We also save integration time as the integration during development slows things down. Miles Ellis: Other possibilities are as an amendment or as a separate part. A Technical Report is a new project and requires an editor; WG5 would set up a task group, the procedures are the same as a standard, with WD, then PDTR (CD equivalent), then DTR (DIS equivalent), and finally TR (IS equivalent). Jerry Wagener: Continuous revision of the standard is another possibility, e.g. using a biennial train model. If we decide to take the TR or amendment route it would be highly desirable to have other groups, not just X3J3, do the work on them. Lawrie Schonfelder: Continuous revision is slow because you are always manipulating the entire document; divide and rule (into TR's) improves this and also allows distribution of the work to multiple groups. Miles Ellis: Doing amendments is really the same as continuous revision. Wolfgang Walter: Continuous revision is bad because the vendors get insufficient time to catch up to the current standard. Jamie Shiers: Would a TR be efficacious in getting vendors to implement new features? Hideo Wada: We would be happy with this approach as long as the TR contained the set of edits to the Standard which would be necessary to incorporate the feature described in the TR. Tom Lahey: We need to be more efficient in the way we produce standards. A TR would be taken notice of if combined with user pressure. Straw Vote: "We wish to pursue the principle of Type 2 TRs for single urgent features." Carried nem con. 11 Review of WD (N1084, N1091, N1097, N1099, N1101, N1105, N1106, N1110) Lawrie Schonfelder: We need to look at the content not at editorial matters. Jerry Wagener: It is premature to decide on the content until we have had more time to digest the papers. The future development procedure (particularly w.r.t. exception handling) also affects the acceptability of the current draft. Straw Vote: "That the technical content of the draft CD is basically acceptable." 8 - 3 - 1. The elicited reasons for the No votes were:  Lack of exception handling,  Concern about interpretation 125,  Concern about addition of masked ELSEWHERE,  Concern about changes to intrinsic functions,  Concern about the relationship to IEC 559. Wolfgang Walter: Corrigendum 3 ought not to be separate but integrated into the document. 12 First Subgroup Session The committee split into two subgroups, one under Jerry Wagener to review the papers on the draft CD, the other under Miles Ellis to draft a recommendation for future processing proposals. The group reviewing the draft CD papers reported that they had split the comments into two parts. Part one consisted of items that were wholly editorial and should therefore be referred to X3J3 as is. Part two consisting of those items with technical content had been formed into a list of ten substantive items for further review and discussion. The future processing group reported that their recommendation was that three Technical Reports be initiated, to cover exception handling, interoperability and enhanced datatypes. Jerry Wagener: Exception handling should address floating-point only. Full exception handling is too large and too controversial to be done in a timely fashion. There are two ways of doing full exception handling -- local vs. global scoping of exceptions -- one faction will eventually win but not soon enough. Wolfgang Walter: Fortran should copy how other languages (e.g. Ada, Modula 2) do it. Jamie Shiers: CERN wants exceptions to have global scope so we can catch i/o errors in old codes. Lawrie Schonfelder: Making the facility non-extensible would be crippling it. Jerry Wagener: The urgent is for floating-point exception handling and to have it now. 13 Second Subgroup Session The meeting split into subgroups to process the list of draft CD technical questions, plus the proposals for a rationale and a preprocessor. Following reconvention a discussion proceeded on the problems of Interpretation 125 described by paper N1083. After consideration of proposed solutions from John Reid, Larry Rolison and Malcolm Cohen, the meeting agreed that the simpler solution should be taken and Malcolm Cohen was asked to communicate by email with Larry Rolison to ensure that a consensus could be reached at X3J3 next week. 14 Rationale for Fortran 95 The subgroup reviewing the rationale proposal recommended that no separate rationale section be included in the draft CD. Jerry Wagener: It would take too long to get it right, and it is very contentious. Miles Ellis: There is not really a place for it in the standard. Wolfgang Walter: A rationale is useful for the whole language, not just the additions and deletions. A small part of the proposed rationale might be usefully put into Annex C notes. Miles Ellis: A rationale cannot be done retrospectively. If it is thought to be a good idea for Fortran 2000 we could do it by making it an absolute condition for all changes. It is too late for Fortran 95. Jamie Shiers: Rationale already exists in the available textbooks. It does not belong in the standard. 15 Fortran Pre-Processor The recommendation of the subgroup reviewing the several proposals for Fortran pre-processors was that WG5 should not pursue this issue ourselves, neither as a Technical Report nor as part of the standard. However, it was believed that we should look favourably on supporting a Technical Report (of Type 3) if someone else wished to pursue it and had the necessary resources. Straw Vote: "That we communicate our decision on this to X3J3: (a) with other topics in the main paper, (b) as a separate paper or (c) via a separate resolution." 4 - 0 - 4 - 2. Jerry Wagener: We should not make a definitive statement on this for all time. Miles Ellis: It is not suitable for the Fortran 2000 standard and we do not have the resources to do it as a Technical Report ourselves; there does not appear to be a very great demand for it. Lawrie Schonfelder: The subject is not suitable for language standardisation. Tom Lahey: We should be market-driven; if someone is willing to put the work into a Technical Report we should process it. Straw Vote: "That we believe that Fortran Preprocessing is a suitable subject for inclusion in the Fortran standard" 2 - 5 - 3. Straw Vote: "That we believe that Fortran Preprocessing is a suitable subject for inclusion in a collateral standard (e.g. as 1539-3)" 4 - 3 - 3. Straw Vote: "That we believe that Fortran Preprocessing is a suitable subject for a Technical Report of Type 3" 6 - 1 - 3. Straw Vote: "That we believe that Fortran Preprocessing is not a suitable subject for standardisation in any form" 1 - 5 - 4. Jerry Wagener: We should record our position both in the summary paper and in a referring resolution; this is an active discussion topic on X3J3. Miles Ellis: Therefore we should request that they not spend time on this to the detriment of the draft CD. 16 Proposals for the Use of Type 2 Technical Reports Miles Ellis presented a draft of paper N1111 for distribution amongst WG5 members and to SC22. Jerry Wagener: We should use the term ``development body'' as this is the term used in the strategic plan. Lawrie Schonfelder: We should avoid this term in referring to a task group for Technical Report production as this implies a member body or other existing organisation. Tom Lahey: The development bodies for the Technical Reports should be X3J3; experience with the varying string standard shows that it takes too long for WG5 to do it. Wolfgang Walter: The task groups should be international. Jerry Wagener: The strategic plan nominates X3J3 as the primary development body to avoid integration problems. The Technical Report proposal as described deviates from the strategic plan; we should not do this. Miles Ellis: We will need to update the strategic plan because it assumes we are producing a single document, but before we begin adding details about Technical Reports to the plan we need to get SC22 approval for our course of action. The procedures and formats for Technical Reports are laid down in JTC1 directives; this step would actually bring us more in line with the directives. We cannot just load the whole effort onto X3J3; the whole idea is to make small international task groups to respond to these urgent requirements. Lawrie Schonfelder: The varying string standard was overseen by WG5. It went quickly not slowly. There were two CD ballots, which is not unusual for a standard, but these were handled efficiently. A task group set up to write a Technical Report must be very small in order to get the work done quickly (12-18 months); this precludes a large group being the development body. Wolfgang Walter: I disagree that this is a substantial departure from our strategic plan. X3J3 is still the primary development body and remains in charge of developing the new standard. This is not an attempt to take all the interesting features away from X3J3, just to get a small number of urgent features done earlier. Miles Ellis: There is no suggestion that anyone other than the primary development body develops the new standard. Production of Technical Reports is a normal WG activity. What is new is our proposed use of Technical Reports in order to facilitate the quick production of single important features; although the directives allow this it is not common practice so we need to ask SC22 for approval. Jerry Wagener: Strategically, nothing has really changed. In the sense of the plan these task groups are development bodies producing exact text for the next standard. Miles Ellis: If we follow this route we must work very quickly. The document outlining the procedure should be sent out to the wider WG5 membership next week and approximately two weeks should be given for comment before forwarding a final version to SC22. The actual proposals do not need to go in quite so quickly. Jerry Wagener: We should tie this to the strategic plan. Miles Ellis: If we mention the strategic plan we must send a copy to SC22. The current version of the strategic plan has some old dates in it and needs revision. For SC22 purposes the document should stand on its own. Jerry Wagener: Distribute the proposal to the Fortran community and a slimmed-down version (without the additional detail) to SC22. Straw Vote: "The document is an acceptable basis for distribution to the Fortran community" 9 - 0 - 1. Jerry Wagener: We could appoint interim editors to further the work until the wider discussion is complete. It was agreed that we only appoint interim project editors whose job is actually to gather a task group to do the work, one of whom must be willing to be the official Project Editor. If no-one is willing to be Project Editor, or no NP is ready by the end of June, that project must fold. 17 Review Fortran 90 Maintenance Jerry Wagener: We should produce a Technical Corrigendum 3 so that Fortran 90 is brought up to date with our current interpretation processing. Lawrie Schonfelder: From a European point of view this is even more critical: it is the standard adopted by CEN that is legally binding (together with its corrigenda). The change-over to Fortran 95 will not happen until after the DIS ballot. Miles Ellis: The practical issue is that the change-over does not occur in the real world until much later. But ISO might not be happy balloting for a corrigendum that might not be published until after the IS has been replaced. Lawrie Schonfelder: Once a DIS is registered no further changes are allowed, so we should continue processing corrigenda until then. Miles Ellis: It is probably best to batch them all up rather than produce a Corrigendum 3 now and a final Corrigendum 4 in November. 18 Fortran 2000 Requirements 18.1 Additional Features There was general consensus that object orientation was very likely to be important for Fortran 2000, and that X3J3 was the most suitable body to develop this feature. Jamie Shiers agreed to produce a ``maximalist'' OO paper, Malcolm Cohen to produce a ``minimalist'' paper, in order to facilitate more productive discussion of requirements. Parallel sections and HPF directives were proposed as requirements in N1102 from the Russian member body. Lawrie Schonfelder warned against adding parallel sections as embedding the architecture so strongly in the language has performance disadvantages in the long run. Malcolm Cohen said that we should avoid any premature standardisation of HPF directives until they were seen to be successful. 18.2 Language Evolution (Reduction of Features) Tom Lahey: Fortran is too big and needs to have old redundant features removed. All obsolescent items should be deleted in Fortran 2000. Lawrie Schonfelder: The corollary is that we should make lots more features obsolescent in Fortran 2000. Straw Vote: "All obsolescent features in Fortran 95 should be deleted in Fortran 2000." 7 - 0 - 4. Tom Lahey: The old forms of the relational operators should be made obsolescent (see Russian comment in N1102). Straw Vote: "That storage association, as defined in the present standard, should be made obsolescent in Fortran 2000." 5 - 3 - 3. Straw Vote: "ENTRY should be made obsolescent in Fortran 2000." 9 - 0 - 2. Straw Vote: "BLOCK DATA should be made obsolescent in Fortran 2000." 8 - 1 - 2. Straw Vote: The old forms of the relationals should be made obsolescent in Fortran 2000." 4 - 2 - 5. Tom Lahey: The DATA statement is hard to implement but we cannot delete it if it still has some function. Lawrie Schonfelder: The DATA statement is irregular and should be removed. Improved array constructors which can produce multi-dimensional arrays would provide superior functionality. Straw Vote: "The DATA statement should be made obsolescent in Fortran 2000." 5 - 2 - 4. Straw Vote: "Add array constructor enhancements to Fortran 2000 to handle DATA functionality." 7 - 0 - 4. Jerry Wagener: I would like to remove all statement ordering constraints between the specification statements. 19 Any other technical items 19.1 IEC 559 Discussion Wolfgang Walter presented the DIN position that IEC 559 and other arithmetic standards are becoming increasingly important and that we must address these issues sooner rather than later. Exception handling is only one area addressed by these standards. There was general agreement on the important of these standards but it was felt that it was too late to do anything further in Fortran 95 than has already been done. 19.2 Standards Copyright Wolfgang Walter reported on the difficulty in Germany in producing an unofficial translation of IS 1539-1 due to copyright. Miles Ellis pointed out that the copyright of the standard is currently owned by ISO and therefore the translator must get written permission from them. The whole question of copyright is an active topic in SC22. Lawrie Schonfelder pointed out that there is no copyright on the CD, the copyright only being transferred to ISO when the document reaches the DIS stage. Further, the working group is required by the directives to maintain an updated WD (in which there is no copyright) and there should be no problem making that available. 19.3 Operator Overloading Restrictions Wolfgang Walter: Currently the operands to user-defined operators must have INTENT(IN), which precludes them from being POINTERs. We are programming important applications in C++ because we need operators that modify their arguments. Jerry Wagener: This would lead to indeterminism. Wolfgang Walter: It can be used judiciously. Jamie Shiers: If you use the + operator to modify its operands no-one will be able to maintain your code. Lawrie Schonfelder: This kind of feature can be useful but it is very easy to shoot yourself in the foot. Malcolm Cohen: This feature is already provided by functions. Wolfgang Walter: Using functional notation is completely unacceptable, only algebraic notation is acceptable. Lawrie Schonfelder: Algebraic notation ought not to be used for non-algebraic operations; there is no algebra' in which the arithmetic operations modify their operands. Jerry Wagener: A paper is needed with a concrete example to explain why this is necessary. Wolfgang Walter: Allowing POINTERs to have INTENT(IN) could get around our problems. The semantics required would be that if a pointer had INTENT(IN) the pointer could be defined but not have its pointer association status affected. 20 Review of WD: Concluded The meeting considered and agreed on the contents of the paper to be forwarded to X3J3 next week, setting out the requirements for the draft CD. Paper N1084 requested that the masked ELSEWHERE construct be removed from the draft CD, as it was not a part of the WG5 nor the X3J3 requirements. Email arrived from Dick Hendrickson explaining why masked ELSEWHERE had been added. Straw Vote: "X3J3 should be asked to remove masked ELSEWHERE from the draft CD." 4 - 3 - 4. 21 Electronic Distribution Miles Ellis presented paper N1077. Jamie Shiers offered CERN as a central server for WG5 papers and said there were no problems restricting access to subdirectories as required for private committee documents. Malcolm Cohen suggested that a mirror site would be needed in the USA and would be useful in the UK. Lawrie Schonfelder pointed out the need to establish formal procedures for electronic submission of meeting papers. The was general agreement with the proposal. Miles Ellis agreed to notify the WG membership of the correct procedures once a trial system is set up. 22 Strategic Plan Update Formal Motion (Cohen/Schonfelder): "That the convenor update the strategic plan, including the schedule therein, to reflect the position at this meeting. Carried nem con. 23 Resolution Processing: Thursday Formal Motion (Schonfelder/Shiers): In the resolution on Fortran Preprocessors, change "by auxiliary standards" to "means other [than]" 9 - 0 - 1. Meeting adjourned at 7pm. 24 Future Meetings Jerry Wagener provided details of the November meeting place; the hotel is on the outskirts of San Diego and is inexpensive, as is the food. Ted Terpstra will be the local representative. Miles Ellis: I will try to get more countries actively involved in Fortran standardisation at the SC22 meeting. Tom Lahey: Given advance of technology and economic circumstances we should anticipate people participating electronically in meetings. Jerry Wagener: Hotel charges for phone access often limit email participation. 25 Adoption of Tokyo Resolutions (N1116) Resolutions T1-T13 were carried by unanimous consent. Resolutions T14-T16 were carried by acclamation. 26 Meeting Closed At 11am.