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: Unanimouslybill@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