[comp.lang.fortran] Report on WG5 meeting in Paris

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