dietrich@cernvax.UUCP (Dietrich Wiegandt) (09/27/88)
ISO/IEC JTC1/SC22/WG5 Meeting, Paris, 19-23 September 1988 An Informal Report by Miles Ellis THIS REPORT IS A PERSONAL VIEW OF THE DISCUSSIONS AND CONCLUSIONS OF THE WG5 MEETING HELD IN PARIS, 19-23 SEPTEMBER 1988. WITH THE EXCEPTION OF THE REPORT OF THE FORMAL RESOLUTIONS, EVERYTHING THAT FOLLOWS IS THE AUTHOR'S PERSONAL OPINION AND HAS NO OFFICIAL STATUS. Summary This was a traumatic meeting. We started with fears of a major split and ended with the hope that this could be avoided. As far as ISO is concerned we have a finally defined language, to be known as Fortran 88, that is acceptable to all SC22 member bodies (with the possible exception of the United States). After much soul-searching it was agreed that if it is the only way to avoid a split and two, incompatible, standards then a Subset of Fortran 88 could be defined to meet the specific needs of the U.S. Fortran community. It seems probable that there will be a new ISO Fortran language by the start of the next decade. 1. The Purpose of the Meeting For many years ANSI/X3J3 has been developing a draft Fortran standard to replace the current International Standard 1539-1980 (also known as American Standard X3.9.1978). In May of last year X3J3 voted to forward its current document (referred to as S8.104 by X3J3) to ISO for comment by national member bodies of SC22 in parallel with the U.S. public comment. On receipt by SC22 this document became known as Draft Proposal 1539 (or simply DP1539). By submitting S8.104 to SC22 in this way X3J3 completed the first part of the work which had been delegated to it - namely to produce a revised draft standard. DP1539 was then submitted to a ballot of the member countries of SC22 with the following result: Yes 9 No 7 Not voting 4 The primary job of WG5 at this point was to attempt to resolve the reasons for the NO votes in such a manner as to ensure that none of the YES votes changed their vote. The Paris meeting of WG5 therefore had as its primary aim the modification of the content of DP1539 in such a manner as to obtain consensus among the SC22 membership. 2. Analysis of the SC22 Vote As part of the initial business of the meeting, the Convenor (Jeanne Martin) summarised the votes and the key issues raised. The countries voting YES were Austria (A), Belgium, Denmark, Finland, Hungary, Italy, Netherlands (N), Sweden, USSR. The countries voting NO were Canada (Ca), China (Ch), France (F), Germany (G), Japan (J), United Kingdom (UK), United States. The countries who did not vote were Bulgaria, Czechoslovakia, Norway, Turkey. The following issues were mentioned in two or more of the comments attached to NO votes (or the YES votes of Austria or the Netherlands): Add bit facilities 6 (A, Ca, F, G, N, UK) Add pointers 5 (Ca, F, G, N, UK) Add blank significance 5 (Ca, F, G, N, UK) Support multi-octet characters 4 (Ca, Ch, J, N) Remove RANGE 4 (Ca, G, N, UK) Add exception handling 3 (F, N, UK) Reduce language complexity 3 (Ca, F, N) Add hexadecimal, octal and binary edit descriptors 2 (Ca, UK) Add stream I/O 2 (G, UK) Remove [ and ] 2 (A, G) Remove IDENTIFY 2 (N, UK) Change or simplify IDENTIFY 2 (Ca, G) Simplify precision 2 (G, N) Remove passed-on precision 2 (G, J) Change procedure overloading 2 (G, J) Simplify modules 2 (Ca, N) Remove user-defined operations 2 (J, N) (Procedural matters) A new standard is needed now 2 (N, UK) Methods for language evolution are needed 2 (N, UK) Subsetting or partitioning is recommended 2 (F, N) In addition a number of items were mentioned by only one country, such as Add varying character (G) Add binary, octal and hexadecimal constraints (Ca) Remove modules (J) etc. 3. Relationship between WG5 and X3J3 All those present at the meeting were, of course, fully aware of the results of the U.S. Public Comment and of the subsequent actions of X3J3. Since DP1539 had been prepared by X3J3 it was felt by everyone that it would be highly desirable for all concerned if its subsequent refinement to DS1539 (Draft Standard) was also carried out by X3J3. A substantial amount of time was therefore devoted to considering how best to ensure that WG5 and X3J3 continued to work together. In particular, the first item of technical business was the presentation of the three Plans remaining from the Jackson meeting of X3J3. 4. Consideration of Plans Before considering detailed action in response to the SC22 vote, WG5 listened to presentations of various plans for the production of the next revision of DP1539. These presentations commenced on the afternoon of the first day (Monday), as soon as the formal opening business had been completed, with the X3J3 plans. Dick Weaver and Ivor Phillips presented their own plans, as modified by the discussions and compromises from Jackson, while Andy Johnson presented John Reid's plan. [John had not intended to be at the Paris meeting; at the last moment he decided to go, but as Andy had prepared his presentation already he went ahead with it anyway]. Following this item on the agenda there was a further item for "Other Plans". There was only one other plan, requested by the U.K. and presented by Lawrie Schonfelder. This was a variation of the ABMSW plan presented at Jackson as a "Layered Model" by Brian Smith and was, presumably, the same as that which was discussed in the rather heated debate on the last day of that meeting. [I say "presumably" because there was no text at Jackson; WG5 had a complete revision of S8 described as "A proposed revision of X3.9-1978 by Jeanne Adams, Walt Brainerd, Jeanne Martin, Brian Smith and Jerry Wagener"] Following discussions of all four plans, both individually and collectively, there was a proposal that the plans proposed by Dick Weaver and Ivor Phillips should not be considered as a basis for a revised ISO Standard. This proposal was carried by an overwhelming voice vote. [There appeared to be only two, or possibly three, NO votes out of around 40]. From this point on, therefore, all discussion was aimed at producing (1) a compromise between the Reid and "Schonfelder" plans, and (2) ensuring that this compromise plan would satisfy those countries who had voted NO. 5. Technical Issues The next two days (Tuesday p.m. onwards) were devoted to the discussion of various technical items. These arose in two ways. One group was based on papers already submitted by various member bodies concerning items raised by them in their SC22 ballots. The other group consisted of items in which the Reid and Schonfelder (ABMSSW) plans differed and where no immediate compromise was obvious. There were three particular items which were likely to have a direct bearing on country votes - varying characters and stream I/O (G), and multi-octet characters (Ch and J). Once all the items had been discussed a series of straw-votes were taken - first on individual items and then on combinations of them. At this stage all votes taken were individual ones, but later in the week country votes were also taken. The only exception to this procedure was multi-octet characters where after an initial straw vote I was asked to consult with the Japanese delegation and arrange further meetings of interested parties. The straw votes taken at this stage were: Allow module procedures 22/5/9 Add Integer KIND= 30/6/1 Allow parameterised derived types 8/14/15 Add vector-valued subscripts 18/6/13 Add INCLUDE (in the Standard/in an appendix/No/?) 13/16/7/1 Add "structures" in COMMON 11/13/13 Add pointer dummy arguments 18/6/13 Allow ELSEWHERE 12/7/18 Add varying characters (as an intrinsic type/via a module/No/?) 12/11/1/10 Add Bin/Oct/Hex edit descriptions 22/1/11 Add Bin/Oct/Hex constants 21/3/11 Add intrinsic(s) for case conversion (UC or LC/gen. TRANSLATE/No/?) 3/13/5/14 Add Logical KIND= (Now/in future/No/?) 18/1/9/7 Allow Sig. blanks in new source form 28/1/4 Add support for multi-octet characters (KIND=/NCHARACTER/No/?) 30/4/1/1 [Note: "Add" means "relative to DP1539"] Several combinations of these items were then straw-voted but as these are difficult to summarise and were superseded later in the week I shall not record them here. Multi-Octet Characters were deferred for further discussions. After several private discussions with the Japanese delegation, and a public meeting of around 10 interested people during which an alternative interpretation of KIND= was discussed, I was delighted to be able to inform WG5 on Thursday morning that the Japanese delegation had agreed to support the KIND= proposal, as included in the printed version of the ABMSSW proposal, with some minor detail modifications. On a personal level I would like to say how pleased I was at this outcome, having been given the task of working with the Japanese on this topic after the Fort Lauderdale meeting. 6. A Note about WG5 Voting Procedures As an ISO Working Group WG5 operates under ISO rules. In particular, all those participating in Working Group activities do so as Individual Experts. Thus, just as with X3J3, votes are normally taken on an individual basis. However, before a Draft Proposal can become a Draft Standard, and before that become an International Standard, it must be approved at the next higher level - SC22. At that level all votes are by national member bodies not by individuals. When it comes to major items of business, therefore, it is useful for WG5 to know what is the likely vote at the higher level. For this reason WG5 often takes "country" votes as well as individual votes. In these votes the head of each national delegation will vote according to how he/she feels the country would vote in SC22. This may be easily determined at the meeting, or it may be difficult. Thus Andy Johnson often abstains on behalf of the U.S. because he feels that those X3J3 members present are not sufficiently representative on a particular issue to indicate how X3J3 would vote as a whole. An extremely important issue at this meeting was to establish what effect any proposed technical changes to DP1539 would have on country votes at the next ballot. Once the individual technical issues had been discussed therefore, most of the subsequent votes were held on both an individual and a country vote. 7. The Technical Content of Fortran 8X An initial draft of Resolution R2 (see below) included almost all the items voted on favourably. The heads of the delegations were then asked if this list was likely to produce a YES vote from their country. EVERY COUNTRY SAID YES. This was encouraging! However the list of items added was felt by many to be such as to delay the standard for too long and so efforts were then made to search for a compromise. That compromise is described in Resolutions R2 and R7. At the end of the meeting Resolution R2 (the form of the language) was carried by 30-2 with 5 abstentions (the two NO votes coming from Ivor Phillips and Dick Weaver), and by 8 countries to 0, with the U.S. abstaining. Resolution R7 (to created a Standard Module for varying characters) was carried by 33-1 (Ivor Phillips) with 3 abstentions, and by 9 countries to 0. 8. Relationship between WG5 and X3J3 (continued) It was apparent to all that the language defined in Resolution R2 would probably not be acceptable to X3J3 on the basis of its position at the last two X3J3 meetings. It was equally obvious to everyone that everything possible should be done to avoid a split. Notwithstanding X3J3's (and WG5's) long-standing distrust of subsets it seemed to many that one possible solution (maybe the only possible solution) was for there to be two languages - one being a true subset of the other. One problem was how to express this to X3J3. Various, unsuccessful, attempts were made to draft a formal resolution but eventually it was decided that the best method would be to have a straw vote - the result of which would be formally minuted to record WG5's opinion. Ivor Phillips was asked to speak for the "conservative" element on X3J3 and the finally agreed wording was as follows: "WG5 considers the concept of subsets to be abhorrent. However an appropriate subset would be accepted in order to assure a single world- wide Standard for Fortran." The votes on this were: Individuals 27/3/6 Countries 6/0/3 The countries abstaining were France, the United Kingdom and the United States. It was the very sincere wish (I believe) of all WG5 members that this would enable the production of a Standard which would meet the stated requirements of the world-wide Fortran community and also, if necessary, of an International Subset to meet the stated requirements of the United States Fortran community. 9. The Paris WG5 Resolutions The resolutions which were voted on at the conclusion of the meeting are appended to this report, together with the voting figures. There follow some brief personal notes of explanation where the text of the resolution might not be self-explanatory to non-WG5 members. R1 It appears that X3J3 has never been formally informed by ANSI that it had been given, and had accepted, the responsibility of producing a draft International Standard. R2 The first two documents (SC22 N464 and N495) contain the responses to the SC22 letter ballot. Since the U.S. voted NO on the grounds that it had not yet completed its own public comment period it was agreed that the X3J3 responses to the major issues raised in that comment were the best information available as to the view of the U.S. The document referred to in (b) as ISO/IEC JTC1/SC22/WG5 N302 is the official designation of the September 1988 draft of the ABMSW plan, as presented to WG5. Items in (b) therefore already have text; items in (c) do not. The document referred to in (c) as ISO/IEC JTC1/SC22/WG5 N316 is the official designation of the August 21, 1988 draft of /COMMON/ FORTRAN, as presented to WG5. R5 There was a strong feeling that now that we had full agreement on the technical content of the language we should press on as quickly as possible. The intention is to have an informal letter ballot of WG5 delegations after the November X3J3 meeting in order to confirm their positions. Assuming that this passes then SC22 will be asked to carry out a formal ballot of its members on this revised language. In order to allow for a possible X3J3 ballot this request will not be forwarded until after the February X3J3 meeting, which will still leave time for the results to be available for next year's WG5 meeting (July 7-11). This resolution sets down this timetable. R9 It was felt that the comprehensive attempts to obtain public reaction, both positive and negative, in the U.S. and in the U.K. had not always been mirrored in other countries. This resolution was an attempt to persuade all countries to get as much public comment as possible to assist them in preparing their next (final?) SC22 vote. R11 A Fortran 8X compiler, complete apart from the code generation phase, was demonstrated during the meeting. It was felt that it would be useful to submit all program fragments to this compiler. - - - - - R1 LETTER CONCERNING INTERNATIONAL FORTRAN STANDARD That WG5 requests SC22 to ask the US member body that X3J3 be reminded that X3J3 had been given the responsibility to develop the international standard for Fortran as well as the American national standard. Carried: 35/0/2 and 9/0/0 R2 REVISION OF DP1539 That WG5 agrees, based upon the ISO member bodies' comments as documented in ISO/IEC JTC1/SC22 N464 and ISO/IEC JTC1/SC22 N495, and upon the X3J3 straw votes documented in X3J3/221 and X3J3/224, that DP1539 be revised in the following way: a) in accordance with X3J3/S16 (S16 is a list of editorial changes) b) as per the text in ISO/IEC JTC1/SC22/WG5 N302 with regard to the following features 1 remove the concept of deprecation (US) 2 remove RANGE/SET RANGE (Ca,D,NL,UK,US) 3 remove ALIAS/IDENTIFY (Ca,D,NL,UK,US) 4 remove specified REAL/COMPLEX precision (REAL(*,*)) (D,J,NL,US) 5 remove internal procedures (US) 6 remove square brackets for array constructors (D) 7 add pointers (and associated facilities) (Ca,F,D,NL,UK,US) 8 add MIL-STD bit intrinsic functions (A,Ca,F,D,NL,UK,US) (but with original MIL-STD names restored) 9 add significant blanks to free form source (Ca,F,D,NL,UK,US) 10 change host association to use association (US) in module procedures and remove host association 11 add parameterization (KIND=) to INTEGER (UK) 12 add parameterization (KIND=) to REAL/COMPLEX (D,J,NL) 13 add parameterization (KIND=) to CHARACTER so as to (Ca,Ch,F,J,NL) allow multiple character set support 14 add the INCLUDE statement (US) c) text to be developed 1 remove user-defined elemental functions (US) 2 remove the new form of the DATA statement (US) 3 change interface blocks to that described in (US) ISO/IEC JTC1/SC22/WG5 N316 4 change array constructor syntax to use I/O syntax (US) 5 remove parameter to derived types (US) 6 add stream I/O intrinsic functions (D,UK) 7 add binary, octal and hexadecimal constants and (NL) edit descriptors (Ca,NL,UK) 8 add parameterized LOGICAL (KIND=) (A,Ca,F,D,NL,UK,US) The codes alongside each point denote the member bodies which mentioned the point in their comment. The abbreviations used are: A - Austria, Ca - Canada, Ch - China, F - France, D - Germany, J - Japan, NL - Netherlands, UK - United Kingdom, US - United States. Carried: 30/2/5 and 8/0/1 R3 WG5 AND X3J3 COOPERATION That WG5 urges X3J3 to accept the plan passed as resolution R2 as the draft proposed standard for Fortran 8X. Carried: 32/2/3 and 8/0/1 R4 NAME OF LANGUAGE That WG5 records its intent that Fortran 8X will be called Fortran 88, based on the 1988 date of passing resolution R2. Carried: 30/0/7 and 7/0/2 R5 A REVISED FORTRAN STANDARD IS NEEDED NOW! That WG5 believes timely release of a revised Fortran standard to be critical and therefore establishes the following procedure and milestones: September 23, 1988 WG5 adopts plan for revision of DP1539, according to resolution R2; Convenor arranges for prepar- ation of revised text. October 21, 1988 Draft text for revised DP1539 distributed to X3J3. (November 13-18, 1988 X3J3 meeting) December 5, 1988 Draft, with possible editorial changes and correction of technical errors which might be recommended by X3J3, distributed by Convenor to WG5 for letter ballot authorising the Convenor to forward the draft to SC22. January 20, 1989 End of WG5 letter ballot. (February 17, 1989 End of X3J3 February 1989 meeting) If WG5 approves the draft, the Convenor forwards it to SC22, with possible editorial changes and correction of technical errors which might be recommended by X3J3 and as a result of WG5 ballot comments, after the February 1989 X3J3 meeting for further processing by SC22. The Convenor will arrange with SC22 the date of forwarding the draft so that the SC22 review period will be completed before the July 1989 WG5 meeting. Carried: 24/4/9 and 6/0/3 R6 WG5 REPRESENTATION AT X3J3 MEETING That WG5 commission Gerhard SCHMITT (or an alternative to be named by the Convenor) to attend the next X3J3 meeting (November, 1988), for the purpose of helping communicate the WG5 position to X3J3. Carried: 36/0/1 and 9/0/0 R7 VARYING CHARACTER MODULE That WG5 requests the German member body to prepare a proposal for a Fortran module for varying character and the WG5 Convenor subsequently to request SC22 to split the work item to allow standardization of the module. Carried: 33/1/3 and 9/0/0 R8 WG5 DELEGATION AT SC22/AG MEETING That WG5 commission Gerhard SCHMITT to represent the WG5 Convenor at the SC22/AG meeting October 17-19, 1988, with Brian MEEK as alternate. Carried: Unanimously R9 WG5 CONSULTATION That WG5 urges all its member bodies to ensure, at the time of public comment on a draft proposed standard, the widest possible distribution of the document within their respective countries, and to obtain reasoned technical comment, both positive and negative, from the largest possible number of Fortran users. Carried: Unanimously R10 VALIDATION That WG5 requests the British member body to investigate the possibility of preparing a validation suite for Fortran 88 processors. Carried: 31/0/6 and 8/0/1 R11 TESTING EXAMPLES That WG5 requests members of the "Alvey Software Engineering Portable Package Framework/Fortran 8X Tools Project" to test the sample programs and program fragments contained in the revised DP1539 to be prepared in October 1988 and to report any suggested changes to the Convenor by November 21, 1988. Carried: 30/2/5 and 8/0/1 R12 APPRECIATION OF X3J3 WORK That WG5 re-affirms its appreciation of the work of the X3J3 committee in preparing the draft proposed standard (DP1539) for balloting in SC22. Carried: Unanimously R13 VOTE OF THANKS That WG5 would like to express its appreciation to the Convenor (Jeanne MARTIN), the Chairman (Bert BUCKLEY), the host (Christian MAS), the Organiser (Claude BOURSTIN), to AFNOR and its staff, and to those organizations who provided further support and who have contributed to the success of the meeting. Carried: Unanimously
bill@hcx2.SSD.HARRIS.COM (10/03/88)
Well, I found several items from the WG5 meeting surprising, to say the least. For instance, I am amazed that so many people felt that demonstrating a lexer and parser for FORTRAN/8x proves that a compiler can be developed in "a timely manner"!!! This is ridiculous! We developed an Ada lexer/parser in about two weeks; it took another 6 man-years or so to develop a working, usable compiler. Even if this "demonstrator model" included a semantics checker, it still leaves out the hardest part: code generation. Also surprising was the timetable that WG5 adopted. This may work for an ISO standard, but it is hopelessly unrealistic for an ANSI standard. We (X3J3) have not finished processing the comments from the _last_ public review; any changes we adopt, if substantive (and those proposed by WG5 certainly are substantive), must be submitted to a second public review. That requires at least a one-meeting delay, for it requires a letter ballot from X3J3 members. Even if all changes were adopted in Boston in November and a letter ballot initiated, it would be February before the results can be acted upon. There would then be another meeting's delay for the public review. Then those comments have to be answered. In short, there is no hope of an ANSI standard by February. Personally, I think it is hopeless to expect the ISO and ANSI standards to be one and the same now. WG5 is obviously not willing to significantly reduce the language. The comments from U.S. users are clearly overwhelmingly opposed to FORTRAN/8x as it now stands, and they will continue to be so opposed until the language is significantly reduced. If X3J3 ignores those comments, and attempts to pass an ANSI standard similar to what WG5 wants, we will have the same situation as COBOL had in '85. There will doubtless be lawsuits, which will serve to delay the standard another 5 years or so. WG5 can remind X3J3 that we are supposed to be developing an international standard until the cows come home, but that won't change the fact that X3J3 must operate under ANSI rules, and the result is first an ANSI standard, not an ISO standard. That means that we can ignore the overwhelming U.S. negative comments only to our peril. Where is it written that everyone must be able to agree on one language? Yes, it would be nice if they could, but it is obvious to me that they cannot. The European users, it appears at least, want completely different things from FORTRAN than the U.S. users want. One language will never satisfy them all. I think, however, that the international user community should consider the consequences of their actions, even assuming they are successful in achieving the standard they want. First, why is it important to them that the ANSI standard be identical to the ISO? I strongly suspect that it is because most of the vendors are based in the U.S., and they will produce FORTRAN/8x processors only at the behest of the U.S. Government. That means it must be an ANSI standard and a FIPS (Federal Information Processing Standard). Usually, ANSI standards become FIPS virtually automatically. But if U.S. users don't like that language, THEY WON'T USE IT! They will find some reason to get an exception (if necessary) from the government. (Actually, with Ada being mandated by the DoD, there will be very little incentive for government contractors to use FORTRAN anyway.) Those users who don't have to worry about the government will just use something else, probably FORTRAN/77. That will significantly diminish the impetus for vendors to produce quality implementations and provide adequate support. For most vendors, the U.S. market is by far the largest economically, so that is the one they will serve first. If FORTRAN/8x processors can't pay for themselves in sales, they just won't exist. Everyone should remember that, just as vendors cannot unconditionally dictate to users, neither can users unconditionally dictate to vendors. At some point, the economics will take over. To believe otherwise is simple folly.
lamson@sierra.uucp (scott h lamson) (10/06/88)
For the past week or two, any computer vendor coming here I have asked the following question: If there are two Fortran 8x standards (ANSI and ISO), will your company support the ISO standard? if NO, then thank you and goodbye. That's my humble contribution to the economics of F8x... If I were with a computer vendor, I would be asking what is the US response to the draft standard from the consumers. The X3J3 response looks very weighted to vendors from the list I saw, and is admittedly negative. The WG5 response seems to be very consumer dominated, and is very positive. Question: How expensive would it be to provide and support two Fortran compilers? If ANSI is a subset, then the cost would be zero? If not, they still could use the same back-end (some vendors use the same code generator for Fortran, C and ADA now.) You would need a code generator for some intermediate language, I presume. What does that imply for the economics? My best hope right now would be for X3J3 to make no more changes to the draft than would require a second public review, and for both ANSI and ISO to agree on it. The one feature I see that adds the most complexity and seems to have the least support and added functionality is generalized precision. Just give me compiler options to have the compiler implement real/double as 16/32/64/128 bits, and I wouldn't miss it at all. Scott| ARPA: lamson@ge-crd.arpa Lamson| UUCP: uunet!steinmetz!sierra!lamson (518)387-5795| UUCP: uunet!steinmetz!lamson!crd