brainerd@unmvax.unm.edu (Walt Brainerd) (08/15/89)
I mailed this to all members of X3J3; I know some of you in netland
also are interested in what is going on, so am posting to you as well.
We received word of the following in Vienna; I have not personally
seen documents to reflect what I am reporting, but thought the X3J3
membership should know about this ASAP. I am sure Jeanne will send
and official version of what is going on.
X3J3 has voted consistently in opposition to both subsets and
separate standards. However, based on the request of one member of X3J3,
SPARC has rewritten the project proposal for Fortran 8x.
The proposal makes 8x a companion standard to Fortran 77, a kind of superset.
8x would not replace F77 at all, and F77 would remain X3.9;
8x would have an X3.??? number in the 200's.
One of the ironies of all this is that apparently SPARC and X3 are doing
this because they think X3J3 has ignored public requests for a simpler
language, but many of the same folks who want subsets are the ones who
complicated the language with stuff like structures in common, namelist,
DO WHILE, INCLUDE, and processor-dependent character sets.
X3 and SPARC apparently were aware of the X3J3 position, just decided
it was wrong. One likely effect is that ISO will drop F77 as a standard
and adopt F8x, so there will be two American standard Fortrans and
one of them will not be an international standard.
If you have an opinion regarding this matter, you should have a serious
discussion with your X3 representative as soon as possible.
The ballot has already gone out to X3, closing on September 20th.
--
Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
2002 Quail Run Dr. NE
Albuquerque, NM 87122
505/275-0800bill@ssd.harris.com (Bill Leonard) (08/16/89)
As the person who made the request of X3 to retain F77, and since I was at the SPARC meeting for this vote, I thought interested FORTRANers might like to hear what went on from a personal observer, rather than second or third hand. Naturally, you should take this report for what it is: my own observations and interpretations of the actions of others. Any errors contained in this report are wholly mine. First, for those unfamiliar with the standards-making organizations, I'll explain who SPARC is: Standards Procedures and Rules Committee. SPARC is a subcommittee of X3, which is the part of ANSI that deals with all information-processing standards. SPARC sets the rules for Technical Committees (TC), like X3J3, and writes the project proposal that directs what the TC can, and cannot, do. First, let me say that Walt is wrong when he says that X3J3 has voted consistently in opposition to subsets and separate standards. X3J3 has been consistently *divided* on this subject! In several straw votes, X3J3 has been almost evenly divided between 1) neither subsets nor separate standards; 2) a subset; 3) a separate standard. The last vote in which I participated was 13-19 on the subject of retaining F77 as a separate standard -- hardly an overwhelming vote on either side. There were many arguments advanced at the SPARC meeting for and against doing this, but the one argument that seemed to carry the most weight was: "Let the users decide." Even those SPARC members who regard 8x as an improvement over F77 recognized that a large segment of the user community do not feel the same, and they feel it is likely that a significant number of those users would, if they had the choice, not choose 8x over F77. They further recognize that the FORTRAN user base is very large and very diverse, and that one language may not necessarily satisfy all. SPARC concluded, therefore, that users should have the choice, unbiased by governmental pressure from ANSI or NIST, between F77 and F8x. Arguments about simplicity/complexity were not much discussed at the SPARC meeting. However, the magnitude of the change from F77 to F8x was an issue, and it seemed to help convince SPARC that F8x is, in reality, a new language from F77, and should be treated thus. There are several precedents for this action. Extended Pascal was issued as a separate standard, as were Full and Minimal Basic. In particular, Extended Pascal was done as a separate standard (I am told) primarily due to concerns about the magnitude of the change. SPARC seemed to be convinced that F77 -> F8x was of much larger magnitude than Classic -> Extended Pascal. You should realize that a number of the largest users were directly represented at SPARC: Social Security Administration, DoD (several times over), Los Alamos National Labs, etc. The SPARC vote was 13-1, so it was hardly a close decision. Several SPARC members felt that this should, perhaps, have been done sooner, but given the realities of the situation, it was better done late than never. By the way, one SPARC member asked me what I thought the international community would do in response to this move. I declined to speculate on the actions of WG5 or ISO; I merely said that my impression was that opposition to F8x seemed to be much lower in other countries than in the U.S. It seems reasonable to me that, if users really are demanding the features in 8x, then retaining FORTRAN 77 will be a no-op, because they'll all be using 8x. I fail to see why the 8x proponents are opposed to giving the users the chance to choose for themselves; it seems a perfect opportunity for them to prove that 8x is better by letting it win in the marketplace, and that they don't need the big club of ANSI or ISO or the U.S. Government to make 8x a success. -- -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
brainerd@unmvax.unm.edu (Walt Brainerd) (08/19/89)
In article <BILL.89Aug15131702@hcx2.ssd.harris.com>, bill@ssd.harris.com (Bill Leonard) writes: > First, let me say that Walt is wrong when he says that X3J3 has voted > consistently in opposition to subsets and separate standards. X3J3 has > been consistently *divided* on this subject! In several straw votes, X3J3 > has been almost evenly divided between 1) neither subsets nor separate > standards; 2) a subset; 3) a separate standard. The last vote in which > I participated was 13-19 on the subject of retaining F77 as a separate > standard -- hardly an overwhelming vote on either side. As I said, X3J3 has voted consistently against (13-19 is a nice example). > It seems reasonable to me that, if users really are demanding the features > in 8x, then retaining FORTRAN 77 will be a no-op, because they'll all be > using 8x. I fail to see why the 8x proponents are opposed to giving the > users the chance to choose for themselves; it seems a perfect opportunity > for them to prove that 8x is better by letting it win in the marketplace, > and that they don't need the big club of ANSI or ISO or the U.S. Government > to make 8x a success. The objections are very simple. If the work project from the very beginning had been to develop a second standard, instead of revising and extending F77: a) Probably most of us wouldn't have bothered. "New" languages seldom succeed, whatever their virtues. b) If it had been done, a very different standard would have been developed. Fortran 8x has been kludged to death, creating some horrible messes trying to accommodate those who want to make all of the features of F77 be integrated with the new ones. Having caused this mess, now some like Bill say it should stand on its own. This can be nothing more than one more attempt to kill any effort to create a revised, modern Fortran, while using the evolutionary approach to protect the investment in current Fortran programs and programmers. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
bill@ssd.harris.com (Bill Leonard) (08/24/89)
> a) Probably most of us wouldn't have bothered. "New" languages seldom > succeed, whatever their virtues. Does that mean, Walt, that you admit that FORTRAN/8x is a new language? Retaining FORTRAN/77 does not make it so, but its content certainly may. > b) If it had been done, a very different standard would have been > developed. Fortran 8x has been kludged to death, creating some > horrible messes trying to accommodate those who want to make all > of the features of F77 be integrated with the new ones. Having > caused this mess, now some like Bill say it should stand on its own. > This can be nothing more than one more attempt to kill any effort > to create a revised, modern Fortran, while using the evolutionary > approach to protect the investment in current Fortran programs > and programmers. I must say I find it amusing that, having consistently voted against FORTRAN/8x, I am now being blamed for it. :-) I also find it odd that, having consistently voted YES numerous times on the question "Do you approve of the technical content of [latest draft]?", Walt now calls it a "kludge" and a "mess", and says he would do it differently. I find it incredible that anyone can argue for protecting "the investment in FORTRAN programs and programmers", and yet argue against retaining the one product they all currently use: FORTRAN/77. I may be one small voice crying in the wilderness, but I will always support the public's right to choose. What a radical idea for an American! -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
brainerd@unmvax.unm.edu (Walt Brainerd) (08/26/89)
In article <BILL.89Aug23142319@hcx2.ssd.harris.com>, bill@ssd.harris.com (Bill Leonard) writes: > > a) Probably most of us wouldn't have bothered. "New" languages seldom > > succeed, whatever their virtues. > > Does that mean, Walt, that you admit that FORTRAN/8x is a new language? > Hardly. Come on Bill, you know that it is just the opposite. Fortran 8x contains ALL of F77 as a subset. The biggest new feature is an extension of the idea of FORmula TRANslation to arrays. Modules are an extension of the idea of block data subprograms. Etc. Who in the world would design a "new language" and come up with this? > > ... Fortran 8x has been kludged to death, creating some > > horrible messes trying to accommodate those who want to make all > > of the features of F77 be integrated with the new ones. ... > > . . . Walt now calls it a > "kludge" and a "mess" . . . A fairly long leap, but maybe I was a bit strong. The whole thing is not a Kludge and a Mess, but parts certainly are. Some of these are due to adherence to the desirable goal of upwards compatibility with F77; others are there in the (I think) misguided attempt to integrate all old features with new ones. > > I find it incredible that anyone can argue for protecting "the investment > in FORTRAN programs and programmers", and yet argue against retaining the > one product they all currently use: FORTRAN/77. > We all used to use Fortran 66; we all used to ride in stage coaches; we all used to die at age 30. Some of us like to progress. F77 is being retained as a subset of F8x; this provides both the protection and the progress. > I may be one small voice crying in the wilderness, but I will always support > the public's right to choose. What a radical idea for an American! > People who can't see but one side of things often seem to appeal to patriotism, religion, etc. If the "right to choose" is the overriding issue here, then we should have two or three dozen "standards" for Fortran. In this case, the "right to choose" is exercised by a representative body deliberating and making a single choice ("standard"). This is another idea central to American and other democracies! -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
hankd@pur-ee.UUCP (Hank Dietz) (08/26/89)
In article <303@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >we all used to die at age 30. ^^^^^^^^^^^^^ I'm 29, so I guess I better voice my disapproval of 8X right now! ;-) >F77 is being retained as a subset of F8x; this provides both the >protection and the progress. Did I miss someone talking about a Fortran subset standard? I'd be perfectly happy if they kept Fortran 77 active as the subset dialect standard. ;-) I've talked to many folk about the standard, and the comments fall into four catagories: [1] No comment (usually, "I'm afraid to do anything because I don't want to risk offending any of our customers"). [2] I hate the 8x standard and will not use it (usually, "I've always used 66/77, and I'm not gonna rewrite the code nor retrain the programmers" but also folks like me saying "it clearly is a different language and to call it Fortran is dishonest"). [3] I like the standard because I believe it will finally kill Fortran. (Usually, "I want to see us using Ada/Modula2/C++ and all Fortran used to have going for it was that it was consistently implemented *EVERYWHERE*.) [4] I like the standard because we really needed the array extensions, although some of that other stuff.... (Heard only from X3J3 members in favor of 8x....) Most people seem to be [1] or [2]. Have others gotten similar feedback? -hankd@ecn.purdue.edu
bleikamp@convex.UUCP (Richard Bleikamp) (08/26/89)
In article <303@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >In article <BILL.89Aug23142319@hcx2.ssd.harris.com>, bill@ssd.harris.com (Bill Leonard) writes: >> Does that mean, Walt, that you admit that FORTRAN/8x is a new language? >> >Hardly. Come on Bill, you know that it is just the opposite. > ... >Who in the world would design a "new language" and come up with this? > >> > ... Fortran 8x has been kludged to death, creating some >> > ... >> >> . . . Walt now calls it a > "kludge" and a "mess" . . . > >A fairly long leap, but maybe I was a bit strong. The whole thing is not >a Kludge and a Mess, but parts certainly are. Some of these are >due to adherence to the desirable goal of upwards compatibility with F77; >others are there in the (I think) misguided attempt to integrate all old >features with new ones. Walt, why do you feel that attempting to integrate Fortran 77 features with the new 8x features (so both can be used concurrently) is a mistake? If you want to replace the Fortran 77 standard, then you need to accomodate a gradual migration to 8x features, as old programs are enhanced/updated over time. By not allowing co-existance of new and old features you`re forcing users to convert an entire sub-program at a time (if not entire programs) to the "new" form in order to utilize new 8x features. It's likely that this will slow user acceptance of 8x, except for new development. I will agree that if Fortran 77 is retained as a seperate standard, that the committee might have decided that 8x would best be used for new development and therefore could disallow certain combinations of old/new features. If Fortran 77 is retained as an ANSI standard, should X3J3 consider revising the proposed standard, or has the process dragged on too long? ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation
brainerd@unmvax.unm.edu (Walt Brainerd) (08/26/89)
In article <12687@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes: > > Did I miss someone talking about a Fortran subset standard? I'd be perfectly > happy if they kept Fortran 77 active as the subset dialect standard. ;-) > This is an alternative that makes a lot more sense than what X3 is proposing (i.e., two different standards and two different documents). X3J3 is currently conducting a poll to see whether the X3 idea of two standards or the subset idea is preferred, given that one will be forced by X3. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
brainerd@unmvax.unm.edu (Walt Brainerd) (08/26/89)
In article <1592@convex.UUCP>, bleikamp@convex.UUCP (Richard Bleikamp) writes: > Walt, why do you feel that attempting to integrate Fortran 77 features with the > new 8x features (so both can be used concurrently) is a mistake? If you > want to replace the Fortran 77 standard, then you need to accomodate a > gradual migration to 8x features, as old programs are enhanced/updated > over time. By not allowing co-existance of new and old features you`re > forcing users to convert an entire sub-program at a time (if not entire > programs) to the "new" form in order to utilize new 8x features. It's likely > that this will slow user acceptance of 8x, except for new development. > In many cases it is a good idea to allow mixing of old and new features, when it assists migration, as you suggest above. But X3J3 has lost sight of that purpose and is mixing everything, whether it helps anyone or not, making the language unduly complex, when many people are asking for it to be simpler. Let me illustrate this with a recent change: allowing structures in common. At first glance, this seems like a good candidate. Structures (sort of like Pascal records) are new and maybe there would be some reason to put one in common. Now you look up the rules and find out that you can't do this if you have any of the parameterized intrinsic data types in the structure ("short" integers, specified precision reals, Kanji or Ascii or Ebcdic characters, etc). Recent e-mail discussions among X3J3 members suggest that even these restrictions are not sufficient to make things work. So the result of the whole exercise is that you really can't mix the new stuff and the old stuff anyway, except in some very special cases. Adding the "feature" increases the complexity, but worse is the addition of strange restrictions on its use that will be very difficult for a programmer to understand or remember. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
bernhold@qtp.ufl.edu (David E. Bernholdt) (08/27/89)
In article <12687@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: >I've talked to many folk about the standard, and the comments fall into four >catagories: [[ in abbreviated form... ]] > >[1] "No comment" >[2] "I hate the 8x standard and will not use it" >[3] I like the standard because I believe it will finally kill Fortran. >[4] I like the standard because we really needed the array extensions, > although some of that other stuff.... (Heard only from X3J3 members > in favor of 8x....) > >Most people seem to be [1] or [2]. Have others gotten similar feedback? > Although I couldn't afford to plunk down $50 for a copy of the draft standard (I hope somebody is listening at ANSI) and didn't see a copy until after the comment period closed, I'll give you my opinion (in brief) right here: I like it. *Many* of the additions are things that I've gone to a great deal of trouble to try to write portably in F77. They are things that I use *now*. The array additions are great -- I already use BLAS for everything possible. The array extension would make it even simpler. Did you ever try to take a code that uses calls to the double precision BLAS and run it on a machine where you work in single precision? You change all of your BLAS calls to single precision or you insert dummy routines to simply call the single precision version -- and pay for the extra subroutine call. Yes, I know that some vendors, like Cray, have a compiler switch to make everything single precision -- but that only works for variables, not subroutines! Dynamic allocation of memory is also terribly useful -- a colleague of mine wrote an entire subroutine library to handle this in F77 by making calls to the appropriate (and very diverse) system routines that handle this on various machines and enforcing a special calling structure in programs (i.e. calls to anything that wants to use an allocated array must go through an intermediate routine which allocates the array and passes it in to the real routine). This is just one of the many things that 8x would make automatic and *PORTABLE*!!!!! In addition, the source format changes, the new control constructs, new I/O capabilities, new intrinsic functions, are all very useful. I won't go into any more details...you get the idea. So there you have it, at least one person in the world in favor of 8x. Maybe if I can get a good look at the new draft, I can put this in writing to the committee... -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
psmith@mozart.uucp (Presley Smith) (08/28/89)
In article <303@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >In article <BILL.89Aug23142319@hcx2.ssd.harris.com>, bill@ssd.harris.com (Bill Leonard) writes: >> > a) Probably most of us wouldn't have bothered. "New" languages seldom >> > succeed, whatever their virtues. >> >> Does that mean, Walt, that you admit that FORTRAN/8x is a new language? >> >Hardly. Come on Bill, you know that it is just the opposite. >Fortran 8x contains ALL of F77 as a subset. The biggest new feature is >an extension of the idea of FORmula TRANslation to arrays. Modules are >an extension of the idea of block data subprograms. Etc. Who in the >world would design a "new language" and come up with this? Okay Walt... If Fortran 8x contains ALL of F77 as a subset, why did the committee vote at the February meeting, 32,0,2, to change the introduction of the proposed standard, introduction page i line 7 and 8 FROM: "Any standard-conforming FORTRAN 77 program is standard conforming under this standard, with the same interpretation." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TO: "Any standard-conforming FORTRAN 77 program is standard conforming under this standard." Gives one a real warm feeling that if a program is standard conforming under FORTRAN 77 it will execute under Fortran 8x, BUT it's POSSIBLE that it will get a different answer or that the programmer will have to change the program to get it to execute in the same manner as it did on FORTRAN 77. Hum... "Fortran 8x contains ALL of F77 as a subset" you claim? Read on... What about the vote in X3J3 on Document 58, 111-RRR-12, "Extra Precision option for DATA statement", that was DEFEATED on a role call vote by 24-13? To quote from document 111-RRR-12: "The committee (X3J3), in a previous action, REMOVED the Fortran 77 permission for processor to supply extra precision. Comment 338.44 deplores the "extra precision" feature of Fortran 77. Comment 518.24 suggests that the Fortran 77 rule must remain in order to be UPWARD COMPATIBLE from Fortran 77. In particular, standard conforming programs executing on standard conforming Fortran 77 processors will NO LONGER EXECUTE the same way in Fortran 8x. Distasteful as the rule may be the committee should recognize that removing it creates this situation. If this is the intent, it should be explicitly stated." The committee has voted by rejecting 111-RRR-12 to STATE that programs which use this Fortran 77 feature will NO LONGER EXECUTE THE SAME WAY in Fortran 8x. 111-RRR-12 was proposal to ADD this feature back into the Fortran 8x language for upward compatibility. It was defeated. Still think "Fortran 8x contains ALL of F77 as a subset"??? How many other examples are there? NO ONE KNOWS! This standard has become so large and complex, that I'm not convinced today that there are not many other places where language incompatibilities have been introduced between FORTRAN 77 and Fortran 8x. I don't believe that a proper audit has been conducted on this current document out for public review to insure that FORTRAN 77 is still contained in it and that programs that are standard conforming on FORTRAN 77 will still be standard conforming on Fortran 8x and will produce the same results on Fortran 8x. Anyone who believes all of FORTRAN 77 is still in 8x and that their FORTRAN 77 programs will execute without change on a FORTRAN 8x compiler are in for a SHOCK! You asked another good question Walt... who would design a "new language" and come up with this? Maybe you'd like to answer that one in another article on the net. > >> > ... Fortran 8x has been kludged to death, creating some >> > horrible messes trying to accommodate those who want to make all >> > of the features of F77 be integrated with the new ones. ... >> >> . . . Walt now calls it a > "kludge" and a "mess" . . . > >A fairly long leap, but maybe I was a bit strong. The whole thing is not >a Kludge and a Mess, but parts certainly are. Some of these are >due to adherence to the desirable goal of upwards compatibility with F77; >others are there in the (I think) misguided attempt to integrate all old >features with new ones. It's true... certain parts are a kludge and a mess. Does the FORTRAN community want want to live for the next 10 YEARS with a Fortran that is a "kludge" and a "mess" with NO other FORTRAN standard available? That's the CHOICE that is being made IF we don't keep FORTRAN 77 ALIVE and WELL as an ACTIVE standard until the Fortran 8x "mess" is cleaned up. Cleaning up FORTRAN 8x could take several years and another round of public review. I would encourage EVERYONE to write to X3 concerning the NEED to keep FORTRAN 77 as an ACTIVE standard until this "mess" is cleaned up. Walt is one of the members of X3J3 that has supported the proposed 8x standard for years and voted "YES" on this standard as a replacement for FORTRAN 77. If he believes it's been "kludged to death", it certainly makes me worry... If you are concerned about upward compatibility, send your letters of concern about upward compatibility and this "mess" of Fortran 8x to: Fortran Public Review X3/CBEMA 311 First St NW Suite 500 Washington DC 20001-2178 >> >> I find it incredible that anyone can argue for protecting "the investment >> in FORTRAN programs and programmers", and yet argue against retaining the >> one product they all currently use: FORTRAN/77. >> >We all used to use Fortran 66; we all used to ride in stage coaches; >we all used to die at age 30. Some of us like to progress. >F77 is being retained as a subset of F8x; this provides both the >protection and the progress. > >> I may be one small voice crying in the wilderness, but I will always support >> the public's right to choose. What a radical idea for an American! >> >People who can't see but one side of things often seem to >appeal to patriotism, religion, etc. If the "right to choose" is the overriding >issue here, then we should have two or three dozen "standards" for Fortran. >In this case, the "right to choose" is exercised by a representative >body deliberating and making a single choice ("standard"). This is another >idea central to American and other democracies! It's unclear to me that the "representative body" is listening to the concerns of the FORTRAN community. When I meet with my customers, I get words like "our representatives are nothing but 'professional meeting attenders' and that they 'listen to the users, IGNORE them, and then vote the way they (the committee members) want'." (Direct quote from a company from the UK last week.) When I look at the previous public review, I note that many thought the proposed standard was too complicated, to large, etc. The committee removed a 'token' set of features and then added more features to it making the resulting standard that is out for public review LARGER than the previous public review version. Fortunately, the US standards process in the IS a democracy. The PUBLIC does count. Every comment is important. (Even though X3J3 has yet to send answers to people who commented in the first public review...) The fact that X3J3 has NOT yet responded to the first public review is certainly a HOT topic in the groups that MANAGE X3J3. Those groups ARE willing to listen to your comments. No one should confuse X3J3's failure to respond, in a timely manner, to the first public review comments as REQUIRED by the ANSI rules, as a signal that ANSI is NOT concerned about this situation. There is much concern at the X3 committee and above and there is great pressure on X3J3 to comply with the rules. So, send your letters to X3 and X3J3. In this country, EVERYONE has the right to have a opinion on this proposed standard and someone in the ANSI process will review ALL letters that are sent in. And, eventually, you WILL get a response... AND, if you don't like the response, YOU have the right to appeal to the higher ANSI groups as is being done right now with the ANSI C standard. So, send in your letters and express your opinions... Walt and I seldom agree on anything... BUT, I certainly agree with him on this... It's a kludge and a mess!
brainerd@unmvax.unm.edu (Walt Brainerd) (08/28/89)
In article <1598@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes: > > Okay Walt... If Fortran 8x contains ALL of F77 as a subset, why did the > committee vote at the February meeting, 32,0,2, to change the introduction > of the proposed standard, introduction page i line 7 and 8 > > FROM: > > "Any standard-conforming FORTRAN 77 program is standard > conforming under this standard, with the same interpretation." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > TO: > > "Any standard-conforming FORTRAN 77 program is standard > conforming under this standard." > > Gives one a real warm feeling that if a program is standard conforming > under FORTRAN 77 it will execute under Fortran 8x, BUT it's POSSIBLE that it > will get a different answer or that the programmer will have to change > the program to get it to execute in the same manner as it did on FORTRAN 77. > Hum... "Fortran 8x contains ALL of F77 as a subset" you claim? Read on... > Page i is not part of the standard, so it doesn't matter, but I don't know why it was changed. Page 1-2 of the STANDARD, lines 37-39 say "Any standard-conforming Fortran 77 program remains standard conforming under this standard, with the same interpretation;" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ so I guess we don't have to worry about that one. > What about the vote in X3J3 on Document 58, 111-RRR-12, "Extra Precision > option for DATA statement", that was DEFEATED on a role call vote by 24-13? > To quote from document 111-RRR-12: > > "The committee (X3J3), in a previous action, REMOVED the Fortran 77 > permission for processor to supply extra precision. > > Comment 338.44 deplores the "extra precision" feature of Fortran 77. > > Comment 518.24 suggests that the Fortran 77 rule must remain in order > to be UPWARD COMPATIBLE from Fortran 77. In particular, standard > conforming programs executing on standard conforming Fortran 77 > processors will NO LONGER EXECUTE the same way in Fortran 8x. > Distasteful as the rule may be the committee should recognize that > removing it creates this situation. If this is the intent, it > should be explicitly stated." > I personally was in favor of retaining the F77 wording for just the reasons stated, so perhaps we do agree on one thing. However, in a legalistic sense, it is editorial because there is nothing in the standard the controls anything about how much precision a real number has. Though there is the possibility that some implementor could use this as an excuse to change somethine, there is no requirement to do so and I doubt that anyone would > > Still think "Fortran 8x contains ALL of F77 as a subset"??? How many > other examples are there? NO ONE KNOWS! > So far we have zero examples. > > Walt and I seldom agree on anything... BUT, I certainly agree with him on > this... It's a kludge and a mess! I guess we still don't agree on this. My words were that it is NOT a kludge and a mess, but some parts of it are. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
psmith@mozart.uucp (Presley Smith) (08/28/89)
In article <308@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >In article <1598@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes: >> Walt is right... It was only changed in one place, in the introduction, which now reads: "Any standard-conforming FORTRAN 77 program is standard conforming under this standard." >Page i is not part of the standard, so it doesn't matter, but I don't >know why it was changed. Page 1-2 of the STANDARD, lines 37-39 say >"Any standard-conforming Fortran 77 program remains standard conforming >under this standard, with the same interpretation;" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Now, it makes one wonder why it was changed in one place and not the other. If you look at page 1-2, you find a list of incompatibilities that are known. In fact, if Walt... let me finish the sentence that you quoted from 1-2. It says: "Any standard-conforming Fortran 77 program remains standard conforming under this standard, with the same interpretation; however, see 1.4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ regarding intrinsic procedures." The same paragraph goes on to say: "The following FORTRAN 77 features have different interpretations in this standard:" and lists 4 different items: 1. Processor supplied precision derived from a real constant. 2. The named variable in a DATA statment without the SAVE attribute. 3. Differences with padding in input records. 4. The fact that there are additional intrinsic functions in 8x that might conflict with user defined functions. If it doesn't matter, why was it changed? I worry that the committee just missed the one on page 1-2 and will remove it as part of the editorial changes that are being done at the current time on the document that is out for public review. For anyone that does not know, the committee is in the process of making editorial changes to the document that is out for public review. No additional functionality is allowed, but the committee is now trying to fix problems in the proposed standard while it's being reviewed... So... what you see in public review may not be the final document. >> >> Still think "Fortran 8x contains ALL of F77 as a subset"??? How many >> other examples are there? NO ONE KNOWS! >> >So far we have zero examples. The standard documents all the KNOWN examples in 1.4.1. In this complex document, I expect that implementers will find several more when someone really attempts to implement this...
jerry@violet.berkeley.edu ( Jerry Berkman ) (08/29/89)
In article <1598@convex.UUCP> psmith@convex.com (Presley Smith) writes: > >What about the vote in X3J3 on Document 58, 111-RRR-12, "Extra Precision >option for DATA statement", that was DEFEATED on a role call vote by 24-13? >To quote from document 111-RRR-12: > > "The committee (X3J3), in a previous action, REMOVED the Fortran 77 > permission for processor to supply extra precision. > > Comment 338.44 deplores the "extra precision" feature of Fortran 77. > > Comment 518.24 suggests that the Fortran 77 rule must remain in order > to be UPWARD COMPATIBLE from Fortran 77. ... > The extra precision rule allows the processor to chose whether to supply the precision written in the program for constants or to supply more precision. I have run the following program on several machines with different results, and on the same machine with two different compilers with different results. double precision d, extpr real x data d/0.1d0/, extpr/0.1/ x/0.1/ call compare( 'data', d, extpr, x ) d = 0.1d0 extpr = 0.1 x = 0.1 call compare( 'assignment', d, extpr, x ) end subroutine compare( str, d, extpr, x ) character str*(*) double precision d, extpr real x if( extpr.eq.d ) then print *, str, ' using extended precision' else if ( extpr.eq.x ) then print *, str, ' no extended precision' else print *, str, ' *** error ***' endif if ( d.eq.x ) print *, str, ' *** precision doesn''t matter *** ' end Results: use extra precision: DEC Fortran (VMS or Ultrix) and Sun's f77 don't use ext. precis: BSD VAX f77, IBM's VS FORTRAN, Cray's CFT & CFT77 The 1977 standard, page 9-2, lines 14-17, states about DATA statments: "if an nlist entity is of type double precision and the clist constant is of type real, the processor may supply more precision derived from the constant than can be contained in a real datum." I can find no justification for extra precision in assignment statements, although I may have overlooked it. Presley Smith continues: >The committee has voted by rejecting 111-RRR-12 to STATE that programs >which use this Fortran 77 feature will NO LONGER EXECUTE THE SAME WAY >in Fortran 8x. 111-RRR-12 was proposal to ADD this feature back into >the Fortran 8x language for upward compatibility. It was defeated. The problem already exists; we don't need to wait for Fortran 8x. A program can not select whether or not to use the extra precision feature; the processor chooses. I.e. "using" extra precision is sort of like using the fact that files are opened at their beginning. In both cases, you are depending on something not standardized. I don't really care which way the processor does it, but I want them all to do it the same way. It's ridiculous that some standard conforming programs running on a VAX will only run with DECs compiler and others only with the BSD compiler. - Jerry Berkman, Central Computing Services, U.C. Berkeley
khb@road.Sun.COM (Keith Bierman - Advanced Languages - Floating Point Group ) (08/29/89)
In article <1598@convex.UUCP> psmith@convex.com (Presley Smith) writes: > > stuff about f77 codes not running under f8x compilers ... >What about the vote in X3J3 on Document 58, 111-RRR-12, "Extra Precision >option for DATA statement", that was DEFEATED on a role call vote by 24-13? >To quote from document 111-RRR-12: > > "The committee (X3J3), in a previous action, REMOVED the Fortran 77 > permission for processor to supply extra precision. > > Comment 338.44 deplores the "extra precision" feature of Fortran 77. > > Comment 518.24 suggests that the Fortran 77 rule must remain in order > to be UPWARD COMPATIBLE from Fortran 77. In particular, standard > conforming programs executing on standard conforming Fortran 77 > processors will NO LONGER EXECUTE the same way in Fortran 8x. > Distasteful as the rule may be the committee should recognize that > removing it creates this situation. If this is the intent, it > should be explicitly stated." > >The committee has voted by rejecting 111-RRR-12 to STATE that programs >which use this Fortran 77 feature will NO LONGER EXECUTE THE SAME WAY >in Fortran 8x. 111-RRR-12 was proposal to ADD this feature back into >the Fortran 8x language for upward compatibility. It was defeated. My experience in porting many large codes amongst machines from over 20 different vendors is that codes which rely on this feature (and most of the others brought up in debate) are, in fact, not portable now. Users who have _never_ moved their code off the first processor it was coded on _may_ be bitten by this (very rarely, I suspect). Those that moved vendors, or processors (e.g. cdc 7600 to cyber 180) or even compilers (cft 114 -> cft77) are likely to have purged their code of anything similar to this (or simply not care that answers don't match digit for digit ... in fp codes that is an unreasonable test anyway). > >... push for letter writing campagin for two standards.... If you are concerned about having any reasonable chance to write your code in a language which allows for better libraries, easier to use programatic interfaces, and have a reasonable expectation of having your code port write to: > > Fortran Public Review > X3/CBEMA > 311 First St NW > Suite 500 > Washington DC 20001-2178 As being against there being 2 standards. Note that the opponents of the new standard are nearly all in favor of 2 standards, but few (if any) will change their vote against the new standard (poll taken privately and during debate at the Long Island meeting) to For if there is a f77 standard. It is _possible_ that having two standards will somehow promote something ... but the only clear outcome _I_ can see is maintance of the status quo and freezing fortran development for some years. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
psmith@mozart.uucp (Presley Smith) (08/30/89)
In article <123897@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - Advanced Languages - Floating Point Group ) writes: > >If you are concerned about having any reasonable chance to write your >code in a language which allows for better libraries, easier to use >programatic interfaces, and have a reasonable expectation of having >your code port (remainder removed...) I think the information that continues be missed in these debates is that there is NO MAGIC in Fortran 8x. There have been a LOT of new facilities created (and not yet implemented by anyone...) to do many of the things that Keith says... but it's NOT FOR FREE. To use the new facilities, YOU will have to modify and, in some cases, rewrite your code. When you do that, you are either going to go with: 1. A more "pure" Modern Fortran 8x STYLE in which case, you will probably rewrite major portions of your code, OR 2. You are going to use a MIXTURE of Fortran 8x and FORTRAN 77/66 and will live with any problems such a mixture may bring. If you mix FORTRAN 77 and Fortran 8x, then the quote from a previous article by Walt Brainerd applies: "If it had been done (Fortran 8x as a separate standard), a very different standard would have been developed. Fortran 8x has been kludged to death, creating some horrible messes trying to accommodate those who want to make all of the features of F77 be integrated with the new ones." So, mixing of FORTRAN 77 and Fortran 8x is not without it's problems. (Just a side note for those of you who don't know... Walt Brainerd is one of the officers of the X3J3 committee. He's the director of "Technical Work and Language Integration.") If you are going to rewrite your code into the more Modern Fortran 8x, then you have the situation that one of my users found when he read the proposed standard: "My first impression after reading through the proposed standard is that this 'Fortran' is a language with which I am not familiar. There have been so many additions to the language that I think it would be possible to write a standard conforming program that an experienced Fortran programmer would have difficulty recognizing." So, producing pure Modern Fortran 8x programs is not without it's problems either. I know of several companies that are evaluating what language they will be using in new development and some of them are turning to C and Ada because of Fortran 8x. Not because the standard is late, but because it is a new language and in order to really use the new features, they must make significant changes in their source codes anyway. Faced with having to do major work on their code anyway to use the new features of Fortran 8x, some are currently planning to rewrite their codes in C or Ada instead. You should try Ada, Keith. You'd love it and it's available today. You don't have to wait for Fortran 8x. Ada was DESIGNED to have all the capabilities you want in FORTRAN. They were not ADDED ON as in Fortran 8x. In Ada, all the features are integrated and all work as one language.
khb@road.Sun.COM (road) (08/30/89)
In article <1624@convex.UUCP> psmith@convex.com (Presley Smith) writes: > > horror stories about using f8x with f77 existing code ... >So, producing pure Modern Fortran 8x programs is not without it's >problems either. When I first started tracking the standard effort in '85 I took the overview then being presented by the chair, the co-chair and misc. luminaries at ACM '85 and dummied up nice interfaces to the library I was then involved in supporting. Everyone who saw the new interface wanted it, and wanted it yesterday. The only changes necessary were to the variable declarations. No changes to the body of the code was required. I do not believe that it will be very difficult to move the vast majority of existing codes to f8x ... I have only seen a few million lines, so perhaps I am missing something. .... >some are currently planning to rewrite their codes in C or Ada >instead. Those of us who have tried the exercise see a good slowdown from 20% to 500% depending on machine. > > >You should try Ada, Keith. You'd love it and it's available today. I have. I do not think it suitable for mathematical programming, such as I used to specialize in. > >Ada was DESIGNED to have all the capabilities you want in FORTRAN. Not by a long shot. Furthermore features that it should have for real time programming simply don't work (try to write code which executes every 100ms, say. Or take Guy Steele's old challenge to write a correct device driver). >They were not ADDED ON as in Fortran 8x. In Ada, all the features are >integrated and all work as one language. F8x as it existed in 1985 was much more suited to my needs. As it stands it is still much better than Ada. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
brainerd@unmvax.unm.edu (Walt Brainerd) (08/30/89)
Here are some opinions I think should be of interest to this group
regarding the recent discussion of two standards.
This was sent by e-mail to all of X3J3 from
JKING%MILO.Dec.Net@VM53.MACC.WISC.EDU
-------------------------------------------------------------------
From: PHENOC::LONG "Bill Long" 29-AUG-1989 13:12:36.17
To: MILO::JKING
CC:
Subj: dual standards
Hi Joe,
Thanks for the copy of your dual standards letter. I hope this
gets resolved (correctly) soon. Below I have appended the section
from my commentary letter on the subject. It contains the same conclusions,
but from a somewhat different perspective, and in my 'less diplomatic'
language. I feel the section on teaching Fortran is especially important
and has been ignored. If you want, you are welcome to circulate this message.
Bill
---------------------------------------------------------------------------
\sectionhead{V. Dual Standards}
Separate from the current proposal, I would like to address an ongoing topic
of the option of having two separate standards, one for Fortran 77 and another
for 8X. Most of the discussion I have seen to date centers on the views of
either vendors or the apparatus of standards formulation. My perspective is
that of an active Fortran user in an academic setting. From this vantage point,
the concept of a dual standard seems disastrous for several reasons.
\subhead{User options.} The 8X proposal allows users to continue writing
programs using only 77 features if they so choose. No one looses anything by
replacing the 77 standard with 8X. Stick-in-the-mud programmers can stay stuck
while those of us who want the new features can have them.
\subhead{History.} One of the greatest virtues of Fortran is its dynamic
nature. A language survives as long as Fortran has only by evolving and
adopting new features to ``keep up with the times''. Well written, modern
Fortran code would not be recognized as Fortran by someone from 1955. The
current complaints about 8X are reminiscent of the mentality that claimed the
sky would fall if such redundant and silly constructs as blocked-if or
character variables were included in the 77 standard. Some of the current
nay-sayers are as myopic as those twelve years ago. They might even be the same
people!
\subhead{Fortran teaching.} In its current state, computer science departments
avoid teaching Fortran, preferring C or Pascal. In fact, use of Fortran is
intentionally and vigorously discouraged as its an ``ancient'' and ``obsolete''
language. It does not bother me that the CS people do not use Fortran
themselves. However, they have (and use) the power to block the physics
department from teaching Fortran. Their own token Fortran course is negative in
its presentation and pathetic in its content. The effects of these attitudes
are starting to hit home. A whole generation of incoming physics graduate
students do not know Fortran, a situation unimaginable only 5 years ago.
The 8X proposal addresses and eliminates almost all grounds for the complaints
of the computer science priesthood. They might even be willing to teach 8X
rather than trying to assure the extinction of Fortran. Corporations and
laboratories who hope to hire Fortran-literate scientists and engineers in the
future should seriously consider this point and aggressively support the
adoption of 8X. The pipeline is drying up rapidly.
\subhead{Code portability.} The retention of the 77 standard will only
encourage vendors to make their extensions to 77 ever more proprietary. This
may boost the morale of their sales forces and fatten the bottom line in the
near term, but it does the user a great disservice and defeats the whole
concept of a standard. If there are two standards, will all vendors support
both? Especially when the initial implementation of 8X will cost money?
Which language will be ``Fortran''?
\subhead{The cow.} The beneficiaries of adopting 8X are thousands, perhaps
millions, of potential users. The beneficiaries of retaining 77 are vendors who
can milk the 77 cash cow for a few more years. The committee has dangled an
enticing vision of the future in front of the user community. I think the
vendors under estimate the hostility users will show if there is continued
resistance to 8X. A responsible vendor who can look beyond this quarter's
financial report should have already started to implement 8X features as
extensions to their current 77 compilers.
--
Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
2002 Quail Run Dr. NE
Albuquerque, NM 87122
505/275-0800bobal@microsoft.UUCP (Bob Allison) (08/31/89)
>In article <308@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >>In article <1598@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes: > >Walt is right... It was only changed in one place, in the introduction, which >now reads: > Yeah, when Walt mentioned that, I ran around and checked the minutes and the action was never even recorded. I was there, and the intent was clearly to remove that phrase from the draft. Whoever suggested the wording messed up. It should be a simple editorial change to fix up, especially in light of the fact that later in the paragraph it shows examples of places where standard-conforming 77 programs do not have the same interpretation. They also missed the new specification that leading zeroes are insignificant in STOP and PAUSE statements (I know, big deal). I'll have to sit down and think about it, but I feel like there were others also. The change to page i was in response to allowing the change in interpretation of constants in DATA statements. Jerry Berkman has indicated that he prefers such changes, since they reduce the number of uncertainties when coding and I agree. However, I still feel (and yes, I am being picky) that these changes disqualify any attempt to make FORTRAN 77 a subset of Fortran 8x. It isn't a political point of view, but rather a technical one: FORTRAN 77 is not a proper subset of 8x. It is a political solution to make it a subset, in the face of evidence to the contrary. > >The standard documents all the KNOWN examples in 1.4.1. In this complex >document, I expect that implementers will find several more when someone >really attempts to implement this... > Oh, no doubt. That doesn't mean the changes weren't for the better; most of the time they will have been. Keith Bierman noted that most of the people in favor of keeping 77 as a standard will continue to vote NO on 8x. I feel it really hasn't been put to the test yet, and honestly believe that I would be in favor of more radical changes if I knew 77 was still going to be a standard. Most of my concern with 8x is that it is a very different, very new language being forced on people who have no other choice if they currently code in 77. It may be true that keeping 77 will slow down production of 8x compilers, but I'm not sure I believe it. Vendors who don't want to produce an 8x compiler won't do so until market pressure becomes intense. Companies like Sun, who are hungry and tend to try to embrace standards up front, will still produce an 8x compiler. People will either embrace 8x compilers and force everyone else aboard, or not. The presence of 77 as a standard doesn't really seem to affect that much, unless 8x is a bomb. In which case it is a very welcome island of stability and portability. Bob Allison
psmith@mozart.uucp (Presley Smith) (08/31/89)
In article <123964@sun.Eng.Sun.COM> khb@sun.UUCP (road) writes: >In article <1624@convex.UUCP> psmith@convex.com (Presley Smith) writes: >> >> horror stories about using f8x with f77 existing code ... > I said: "To use the new facilities, YOU will have to modify and, in some cases, rewrite your code." I don't believe that translates to "horror stories about using f8x with f77 exiting code..." If you are going to respond to what I said, please at lease quote what I said correctly!!!! What I said corresponds very well with what you said: >The only changes necessary were to >the variable declarations. No changes to the body of the code was >required. You DID have to change the code! You did NOT have to rewrite the code. >I do not believe that it will be very difficult to move the vast >majority of existing codes to f8x ... I have only seen a few million >lines, so perhaps I am missing something. If you want to keep the code in FORTRAN 77 syntax, then there are NO changes to be made. If you want to use modules, array notation, pointers or many of the other 8x features, then YOU are going to have to rewrite at least portions of your code. Those are the facts. > >.... >>some are currently planning to rewrite their codes in C or Ada >>instead. > >Those of us who have tried the exercise see a good slowdown from 20% >to 500% depending on machine. > Sounds like you have a problem in your compilers. We see no slowdown on our machine in executable code that is well written in either C or Ada. We see a slowdown in compiler speed in Ada due to the dependent compilation model (similar to 8x modules) but again, no slowdown in the executable code. >> >>You should try Ada, Keith. You'd love it and it's available today. > >I have. I do not think it suitable for mathematical programming, such >as I used to specialize in. We have customers who are very successfully using Ada in "mathmetical programming." In fact Ada math libraries are available from several companies including QTC in Oregon that work quite well. >> >>Ada was DESIGNED to have all the capabilities you want in FORTRAN. > >Not by a long shot. Furthermore features that it should have for real >time programming simply don't work (try to write code which executes >every 100ms, say. Or take Guy Steele's old challenge to write a >correct device driver). I don't believe that Fortran 8x solves the realtime problems... What in Fortran 8x addresses the realtime problem? I certainly would NOT write a device driver in FORTRAN 77 or FORTRAN 8x. FORTRAN is NOT a language that is suited to writing device drivers. Most people write device drivers in C or assembly langauge. You just made the argument above the Ada was not suitable for mathematical programming... why do you think that Fortran, the FORmula TRANSlation language, is suitable for writing device drivers? Why would we WANT FORTRAN to be suitable for writing device drivers??? >>They were not ADDED ON as in Fortran 8x. In Ada, all the features are >>integrated and all work as one language. > >F8x as it existed in 1985 was much more suited to my needs. As it >stands it is still much better than Ada. My Ada group does not feel that Fortran 8x is better than Ada, but I guess that's getting into the area of religion. Everyone to their right to their own opinion on the subject. Keith, maybe you could implement that 1985 version of Fortran 8x and then you'd be happy...
psmith@mozart.uucp (Presley Smith) (08/31/89)
In article <7560@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison) writes: >>In article <308@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >>>In article <1598@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes: >> >>Walt is right... It was only changed in one place, in the introduction, which >>now reads: >> > >Yeah, when Walt mentioned that, I ran around and checked the >minutes and the action was never even recorded. I was there, and the >intent was clearly to remove that phrase from the draft. Whoever >suggested the wording messed up. It should be a simple editorial change >to fix up, especially in light of the fact that later in the paragraph >it shows examples of places where standard-conforming 77 programs do not >have the same interpretation. They also missed the new specification that >leading zeroes are insignificant in STOP and PAUSE statements (I know, >big deal). I'll have to sit down and think about it, but I feel like >there were others also. Bob, I had not researched this, but made a note at the time that this was a change in the upward compatibility position. In looking through my files I find this vote for this came on 2/17/89 at the Palo Alto meeting. It's clear that the person making the changes to the proposed standard after that meeting failed to pick up part of the wording that was changed. The change comes from the December 1988 Letter Ballot Comments generated by Len Moss of SLAC. His proposal I on page 72 of the Chair's Ballot on S8.110 contains several parts per this summary: O.1 i/8: Delete ",with the same interpretation". [The new MVBITS and RANDOM intrinsic subroutines could change the interpretation of a program and were not covered by the caveat in the section notes... ETC. ... 1-1/7-8: Delete ",with the same interpretation...regarding intrinsic procedures". THIS WAS THE CHANGE THAT WAS NOT MADE... 1-2/21: Change "procedures" to "functions" and after "FORTRAN 77" add ",and for the first time in Fortran introduces several intrinsic subroutines". These edits would have been applied to the S8.110 version of the document and then edited by the editorial committee at some point before the S8.112 document, which is the document that is out for public review, was produced. This vote was part of the vote on the summary in document 112, "Chairs Ballot Comments, X3J3/234 Adoption Recommended by Ad Hoc Group", approved by a vote of 32-0-2. This vote was taken at approximately 9:00 AM on 2/17/89 in Palo Alto. You're certainly right. It's just a failure to make the changes in the document as passed by the committee. >>The standard documents all the KNOWN examples in 1.4.1. In this complex >>document, I expect that implementers will find several more when someone >>really attempts to implement this... >> > This is just one case where the document does not conform to what the committee voted to do. Makes me worry that FORTRAN 77 may not be contained in this document in its original form. Changes in wording or mistakes made in changing the document may have introduced other incompatibilities even by mistake...
hirchert@uxe.cso.uiuc.edu (08/31/89)
Walt Brainerd and Presley Smith are engaged in an argument about whether FORTRAN 77 is a true subset of Fortran 8x. Allow me to try to clarify the situation: Fortran 8x is a superset of FORTRAN 77 in the following sense: A standard- conforming Fortran 8x processor should interpret any program in a manner consistent with the requirements of FORTRAN 77. Implicit is the above are two limitations: 1. It was possible under FORTRAN 77 for a program to be standard conforming on one processor, but not standard conforming on another. The classic example of this is a program which uses an external function without specifying it in an EXTERNAL statement. If such a program is moved to a processor where that particular function name has been made an intrinsic, the new processor will interpret those function references as references to its processor-dependent intrinsic and thus conclude that the program does not conform to FORTRAN 77. In such cases, it is possible that the program will not be regarded as standard conforming by any Fortran 8x processor and/or the program may have a different interpretation because of the differing semantics of the added intrinsic functions. 2. There are cases where FORTRAN 77 gave a conforming processor a choice of interpretations and Fortran 8x may be more limiting. For example, there are situations involving the ends of files that in FORTRAN 77 could have been interpreted as errors but that in Fortran 8x must raise the end-of-file condition. All interpretations allowed by Fortran 8x are also allowed by FORTRAN 77, but not all interpretations allowed by FORTRAN 77 are also allowed by Fortran 8x. The above two limitations are the reason a FORTRAN 77 program cannot be guaranteed to have the same interpretation when run on a Fortran 8x -- it may not have been possible to guarantee that they would have the same interpretation when run on another FORTRAN 77 processor! In other words, truly portable FORTRAN 77 programs will remain portable in Fortran 8x, but if a program has exploited the processor-dependent aspects of FORTRAN 77, then it is possible that the same processor-dependent behavior will not be available and the program will fail under Fortran 8x. The examples cited from section 1.4.1 are _not_ example of incompatibilities between FORTRAN 77 and Fortran 8x; they _are_ examples of places where a Fortran 8x processor might be forced to behave differently from an existing FORTRAN 77 processor based on the same hardware. I agree with Presley that the words "with the same interpretation" should not appear in section 1.4.1. Fortran 8x can guarantee the same interpretation only in those cases where FORTRAN 77 guaranteed that two different FORTRAN 77 processors would have the same interpretation. Nevertheless, the assertion remains that there are no known examples of programs where FORTRAN 77 processors would be required to have the same interpretation, but a Fortran 8x processor would have a different interpretation. Presley, are you aware of any examples that contradict _this_ assertion? (As stated above, the examples in 1.4.1 do not qualify.) Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
khb@road.Sun.COM (Keith Bierman - Advanced Languages - Floating Point Group ) (08/31/89)
In article <1631@convex.UUCP> psmith@convex.com (Presley Smith) writes: >>> horror stories about using f8x with f77 existing code ... >> > >I said: "To use the new facilities, YOU will have to modify and, >in some cases, rewrite your code." I don't believe that translates >to "horror stories about using f8x with f77 exiting code..." > >If you are going to respond to what I said, please at lease quote what >I said correctly!!!! As per the "rules" promulgated by the net I tried to abbreviate several paragraphs into a single sentence. I trust most net readers to understand the process. > >What I said corresponds very well with what you said: > >>The only changes necessary were to >>the variable declarations. No changes to the body of the code was >>required. > >You DID have to change the code! You did NOT have to rewrite the code. My users did not have to change THEIR code. That is the point. All of the new features were completely hidden to those who did not wish to partake. This allows evolutionary code development. >>>instead. >> >>Those of us who have tried the exercise see a good slowdown from 20% >>to 500% depending on machine. >> > >Sounds like you have a problem in your compilers. We see no slowdown It has been a bit since I did the experiment on your hardware, but as reccently as a year ago this was quite true on convex gear. There are, in fact, semantics which if properly maintained reduce the optimizability of C. The convex compiler, at high enough optimization levels (like many other machines ... soon perhaps suns :>) cheerfully breaks C semantics. >We have customers who are very successfully using Ada in "mathmetical >programming." In fact Ada math libraries are available from several >companies including QTC in Oregon that work quite well. I do not assert that it is impossible, it simply does not solve any problem not solved better by f8x. The key difference is that, as described above, f8x allows gradual migration. Conversion of a project to Ada requires a very hefty investment. >> >I don't believe that Fortran 8x solves the realtime problems... What >in Fortran 8x addresses the realtime problem? f8x doesn't ... but that isn't why f8x was designed. Ada was explicitly designed to be employed in real-time embedded systems. While Ada is a good language, it isn't all that hot for the application area it was chartered to work in. >..... >language, is suitable for writing device drivers? Why would we WANT >FORTRAN to be suitable for writing device drivers??? I don't think f8x is suitable for device drivers. I never asserted that it was. I suggest you take your own advice about reading more into the message than is there. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
achille@cernvax.UUCP (achille petrilli) (09/01/89)
Presley Smith writes in response to my article: > >1. FORTRAN 77 permitted a processor to supply more precision derived > from a real constant than can be contained in a real datum when the > constant is used to initialize a DOUBLE PRECISION data object in a > DATA statement. This standard does not permit a processor this > option. Here I believe there is really nothing to complain about: F77 "permitted" a processor to do something one way or the other. It was not something you could RELY upon. Whoever has taken advantage of that must be aware of inherent nonportability, even if we stick to F77. >2. If a named variable initialized in a DATA statement, and does not > have the SAVE attribute specified, FORTRAN 77 leaves its SAVE > attribute processor dependent. This standard specifies that this > named variable has the SAVE attribute. Here again is the same as point 1. I don't see how you can be portable in F77 and RELY on DATA initialized variables to be SAVEd (or not), as this is processor dependent. Being F8x more strict can lead to a change, true, but after all, if one wants a variable to be SAVEd in this case, to be portable, s/he would have to explicitly put it in a SAVE stmt. >3. FORTRAN 77 requires that the number of values required by the > input list must be less than or equal to the number of values in > the record during formatted input. This standard specifies that > the input record is logically padded with blanks if there are > not enought values in the input list unless the PAD = NO option > is specified in an appropriate OPEN statement. I cannot fully judge here, never fell into this trap. But if F77 "required" the input list to be less than or equal to the number of values in the record, it seems to me that not obeying to this rule can produce, at the best, processor dependent results and at worst some run-time error. Again the same as point 1 or 2. And any way there is a way to go back to the previous behaviour. I could say many things (all bad) about OPEN stmt in F77. It is probably the stmt that always needs some change when porting a program, just having to add PAD=NO is just part of routine maintenance. It would have been much better if F77 had taken a more radical approach to OPEN. F8x is now out to fix these problems, don't blame it for past errors. >4. This standard has more instrinsic functions than did FORTRAN 77 > and adds a few intrinsic subroutines. Therefore, a standard- > conforming FORTRAN 77 program may have a different interpretation > under this standard if it invokes a procedure having the same > name as one of the new standard intrinsic procedures, unless > that procedure is specified in an EXTERNAL statement as > recommended for nonintrinsic functions in the appendix to the > FORTRAN 77 standard. This could be a problem, but I see no solution to it, other than not introducing any new intrinsic until year 2099. Many F77 implementations introduce more intrinsic than the std prescribes, so what about 'em ? This way we would have to stop any progress. C is undergoing a standardization process as well. New library functions have appeared, they too could clash with existing names in existing programs, trigraphs have been introduced in ANSI C, existing programs could behave differently, etc. Any std is going to break something, especially in the previously undefined or processor dependent areas. The problem is to minimize those areas. F8x seems to be quite good in this respect as there are very few things that have been broken intentionally. I wrote: >>Let get pragmatic, what should I rewrite under f8x ? do loops, ifs, >>I/O statements ? what ? Presley wrote: >That's up to you. do loops... do you want to use array notation for >an example? If you don't want to use new features, then don't change >your code. What I meant was: do I HAVE to rewrite something otherwise it'll perform differently ? The answer seems to be 'No, you don't have to if you don't need new features'. That's enuff for me. In this respect F77 broke badly F66 with the story of zero-trip loops vs. one-trip loops. Also it gave us a very difficult transition from Hollerith characters to the new character type. Life IS difficult sometimes. Presley writes: >I believe that those that want 8x should have 8x. And those that don't >want it should not have it forced on them. Seems like a simple enough >concept to me. For what I've seen up to now, if you don't want F8x, just stick to F77 stmts in F8x. I don't see any reason to have 2 stds. I have now some clearer ideas (for the time being :-). Achille Petrilli Cray and PWS Operations
mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) (09/01/89)
In article <1073@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: >For what I've seen up to now, if you don't want F8x, just stick to F77 stmts >in F8x. I don't see any reason to have 2 stds. If I were going to write F77, I would MUCH rather use a solid F77 compiler than a new, probably broken, f88 compiler.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu mccalpin@delocn.udel.edu
hallidayd@yvax.byu.edu (09/05/89)
Hank Dietz (hankd@pur-ee.UUCP) in message (<12687@pur-ee.UUCP>) comments >>F77 is being retained as a subset of F8x; this provides both the >>protection and the progress. > >Did I miss someone talking about a Fortran subset standard? I'd be perfectly >happy if they kept Fortran 77 active as the subset dialect standard. ;-) What do you mean by the smiley? I don't care if FORTRAN 77 is called a subset dialect standard or not (it is not presently called such), however, what some people do not seem to be getting though there thick heads is that FORTRAN 77 is retained as a proper subset of Fortran 8x (meaning that ALL FORTRAN 77 code will run under Fortran 8x)! Why must FORTRAN 77 also be graced with the status of a subset dialect (or, as appears the case now, a separate standard)?!? Why is it not enough to retain _FULL_ backward compatibility with FORTRAN 77 (even with the archaic parts of that archaic language)? > >I've talked to many folk about the standard, and the comments fall into four >catagories: > >[1] No comment (usually, "I'm afraid to do anything because I don't want > to risk offending any of our customers"). > >[2] I hate the 8x standard and will not use it (usually, "I've always > used 66/77, and I'm not gonna rewrite the code nor retrain the > programmers" but also folks like me saying "it clearly is a > different language and to call it Fortran is dishonest"). > >[3] I like the standard because I believe it will finally kill Fortran. > (Usually, "I want to see us using Ada/Modula2/C++ and all Fortran ^^^ > used to have going for it was that it was consistently implemented > *EVERYWHERE*.) This is _almost_ certainly true of OLD FORTRAN (it has also usually been the fastest numeric language on most machines of interest---in other words, not counting PCs)! What people like myself are wanting (shall I say dying for?) is a language that can fulfill diverse needs within a mathematical (though not always numeric) framework, with high efficiency. Old FORTRAN fulfilled the narrow needs of some who required only elemental mathematical operations with the possibility of grouping data into arrays. The trouble is that the needs of the scientific computing community (by no means the only group to use FORTRAN, but the group most often cited as the principle users of FORTRAN) have outgrown FORTRAN (even as advanced as VAX FORTRAN) --- we need much more! The concept of FORmula TRANslation, however, is something we most certainly wish to maintain---we like the ability to have our programs look as much like the mathematics of the problems from which they sprung as possible! (Though it is true that Fortran 8x will help significantly with this need with its operator overloading and defining capabilities, routine overloading, and array operations, it really falls far short of being truly Formula translation. I hope Fortran 9x will be much closer. I know I will be there fighting to see that it does, if possible.) > >[4] I like the standard because we really needed the array extensions, > although some of that other stuff.... (Heard only from X3J3 members > in favor of 8x....) See my comments above --- I am not a member of any of the standards committees. For the kind of computing done by the scientific community, the array operations are certainly needed, however, this is by no means all that is needed. The need has long existed for recursive data types to accommodate the needs of newer, faster algorithms (such as many body algorithms that grow as N*log(N), or even as good as N, rather than the old N^2 that only needed matrices --- though it is still the fastest algorithm for sufficiently small N on array processing machines). **Please** don't continue to force us to use a hodgepodge of programming languages that cannot be guaranteed any semblance of the portability that has been one of the strengths of Fortran. > >Most people seem to be [1] or [2]. Have others gotten similar feedback? > > -hankd@ecn.purdue.edu _____________________________________________________________________ / David Halliday \ | | | Internet: hallidayd@yvax.byu.edu or hallidayd@acoust.byu.edu | | BITNET: hallidayd@byuvax or hallidayd%acoust.byu.edu@utahcca | | Us Mail: BYU Physics Department | | 296 ESC | | Provo, UT 84602 | \_____________________________________________________________________/
hallidayd@yvax.byu.edu (09/05/89)
Walt Brainerd (brainerd@unmvax.unm.edu), as to your message (<305@unmvax.unm.edu>) >In article <12687@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes: >> >> Did I miss someone talking about a Fortran subset standard? I'd be perfectly >> happy if they kept Fortran 77 active as the subset dialect standard. ;-) >> >This is an alternative that makes a lot more sense >than what X3 is proposing (i.e., two different standards and two different >documents). X3J3 is currently conducting a poll to see whether the X3 idea >of two standards or the subset idea is preferred, given that one will be >forced by X3. I most certainly prefer the subset idea. Who is being poled by X3J3? I suspect that the venders who have been voting against Fortran 8x because they feel it is to much of a change (it's such a change because FORTRAN has not been keeping up with the times) would prefer to have Fortran 8x be a separate standard so they won't have to market their compilers as subset compilers --- but in reality, this is what a FORTRAN 77 compiler will be (at least as far as I am concerned). _____________________________________________________________________ / David Halliday \ | | | Internet: hallidayd@yvax.byu.edu or hallidayd@acoust.byu.edu | | BITNET: hallidayd@byuvax or hallidayd%acoust.byu.edu@utahcca | | Us Mail: BYU Physics Department | | 296 ESC | | Provo, UT 84602 | \_____________________________________________________________________/
khb@road.Sun.COM (Keith Bierman - Advanced Languages - Floating Point Group ) (09/06/89)
In article <785hallidayd@yvax.byu.edu> hallidayd@yvax.byu.edu writes: >Hank Dietz (hankd@pur-ee.UUCP) in message (<12687@pur-ee.UUCP>) comments > >of a subset dialect (or, as appears the case now, a separate standard)?!? Why >is it not enough to retain _FULL_ backward compatibility with FORTRAN 77 (even >with the archaic parts of that archaic language)? > My agreeing with Presley is a rare event ... but here goes. It is possible for a program to operate (legally) on a f77 processor, but operate differently (or fail) on a f88 processor. As Kurt pointed out there are heuristics which work fairly well. An example: Believe it or not, there are machines upon which open(unit=50,file="oldfile") results in the file being positioned to the END OF FILE. Since f77 did not define the file position after an open (oversight ? ). Nearly all implementations assume OPEN means position to start of data; as do nearly all codes. But there _probably_ are codes which EXPECT to be positioned at END OF FILE ... Under f88 the OPEN is defined to default to start of data, with the option of positioning at the end of data. I am fairly sure that any vendor who had the bizzare default before, will allow that to be the default in f88 also (compiler switch). The upshot is that language lawyers may not assert that all of '77 is in '88 with the same interpretation ... Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
bill@ssd.harris.com (Bill Leonard) (09/08/89)
>> Still think "Fortran 8x contains ALL of F77 as a subset"??? How many >> other examples are there? NO ONE KNOWS! >> > So far we have zero examples. This reminds me of a comment a fellow programmer made to me years ago. I asked if his program was working, and he said, "It's not known not to work." In fact, he hadn't tested it at all, but there were no known bugs! :-) -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
bill@ssd.harris.com (Bill Leonard) (09/08/89)
> I can find no justification for extra precision in assignment statements, > although I may have overlooked it. I think Jerry has hit on the real problem here. The question that the average programmer wants answered is: If I initialize a variable in a DATA statement, will I get the same results that I would get if I use an assignment statement? Rather surprisingly, neither F77 nor F8x address this question. I personally think that a compiler that tried its best to get the most exact answer possible from a given code would be the most desirable. > It's ridiculous that some standard conforming programs running on a VAX > will only run with DECs compiler and others only with the BSD compiler. I think this is a bit strong. Jerry's example tests for equality of floating-point numbers: a definite no-no. Anyone who does that deserves what they get. Nevertheless, I think Jerry has a point, but good luck writing a standard to enforce that. The standard cannot enforce the exact value of answers to floating-point computations: there's too much room for variance (e.g., architecture, optimizations, etc.). This is the type of thing that can only be enforced by the marketplace. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
bill@ssd.harris.com (Bill Leonard) (09/08/89)
> For what I've seen up to now, if you don't want F8x, just stick to F77 stmts > in F8x. I don't see any reason to have 2 stds. > I have now some clearer ideas (for the time being :-). I'll try to clarify why I believe this is insufficient. Let's say I have a customer bidding for a government contract to provide a flight simulator for the new F-1600 fighter jet, an improved version of the F-16. This customer already has an F-16 simulator, written in F77, running on a Whizbang-9000 machine. He is sure that a few minor mods are all that is required to build an F-1600 simulator to meet the contract. He's already gotten an exception from DoD to use FORTRAN instead of Ada (this does happen, by the way). Let us suppose that F8x is out, and F77 is no longer an active standard. Customer's first problem: he has to buy Whizbang's F8x compiler, because their F77 compiler no longer conforms to the FIPS for FORTRAN. After much haggling over price, he pays the bucks. Next problem: the F8x compiler doesn't give the same answers as the old F77 compiler did, even on the same hardware! He complains to Whizbang, who says, "Sorry, but the standard forced us to change that." Next problem: Whizbang has changed NAMELIST to conform to F8x, which is different from their F77 NAMELIST extension. Too bad, Whizbang says, the standard forced us to change. The list goes on... All of these problems can be avoided simply by retaining F77 as a separate standard. Whizbang can still implement F8x, and there will still be these incompatibilities, but F77 customers don't need to worry about them. Perhaps eventually this customer might convert his program to F8x, but meanwhile he has incurred a significant cost for something that should have been virtually free. Note that this customer didn't care about portability: only that the program behaves the same on the same hardware. Say all you want about these features not having guaranteed portability between revisions of the compiler -- Whizbang wouldn't change those things without a very good reason, because they don't want to make their customers mad. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
mike@arizona.edu (Mike Coffin) (09/08/89)
From article <314@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > ...In its current state, computer science departments avoid teaching > Fortran, preferring C or Pascal. In fact, use of Fortran is > intentionally and vigorously discouraged as its an ``ancient'' and > ``obsolete'' language. ... The 8X proposal addresses and > eliminates almost all grounds for the complaints of the computer > science priesthood. They might even be willing to teach 8X rather > than trying to assure the extinction of Fortran. How so? I'm not a member of the priesthood, but from what I've seen of the new standard, it's about the last language I would try to teach to a bunch of undergraduates. The movement in Computer Science seems to be towards smaller, more extensible languages. (Witness the rise of functional and object-oriented languages.) Fortran 8x is huge and monolithic. And, if the traffic on this network is any indication, it's not the easiest language to understand. I'm not putting it down --- you guys know what you need, and I'm in no position to contradict. But I don't think you should count on CS departments flocking to Fortran. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
brainerd@unmvax.unm.edu (Walt Brainerd) (09/08/89)
In article <BILL.89Sep7131506@hcx1.ssd.harris.com>, bill@ssd.harris.com (Bill Leonard) writes: > >> Still think "Fortran 8x contains ALL of F77 as a subset"??? How many > >> other examples are there? NO ONE KNOWS! > >> > > So far we have zero examples. > > This reminds me of a comment a fellow programmer made to me years ago. I > asked if his program was working, and he said, "It's not known not to > work." In fact, he hadn't tested it at all, but there were no known > bugs! :-) > -- You and Presley have been fussing about this for some time. If there is some point to all this, I think the readers would like to hear what it is. Contrary to your insinuations, X3J3 has devoted a lot of time to trying to ensure that this is the case. A subgroup (led by Mike Metcalf of CERN, I think), did a complete reading of the two to check this. Of course, even after very extensive testing there may be a bug, but somehow, I don't think many people will think this is justification for dropping the project! -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
brainerd@unmvax.unm.edu (Walt Brainerd) (09/08/89)
In article <13833@megaron.arizona.edu>, mike@arizona.edu (Mike Coffin) writes: > From article <314@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > > > ...In its current state, computer science departments avoid teaching > > Fortran, preferring C or Pascal. In fact, use of Fortran is > > intentionally and vigorously discouraged as its an ``ancient'' and > > ``obsolete'' language. ... The 8X proposal addresses and > > eliminates almost all grounds for the complaints of the computer > > science priesthood. They might even be willing to teach 8X rather > > than trying to assure the extinction of Fortran. > > How so? I'm not a member of the priesthood, but from what I've seen > of the new standard, it's about the last language I would try to teach > to a bunch of undergraduates. The movement in Computer Science seems I dont think I wrote the above, but that is OK, because I have no serious disagreement with it. It seems to me that teaching the "modern" subset of Fortran 8x would not be so bad. There would be the additional advantage that the students would be learning a language actually used. But I have never thought the particular language chosen to teach CS is all that important. After learning Pascal, a good student should be able to write C or Fortran programs after a weekend of study. I hope that engineering and science departments will continue to expose students to Fortran; now there will not be the excuse to avoid teaching them how to effectively use data structures, recursion, modules, etc. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
psmith@mozart.uucp (Presley Smith) (09/09/89)
In article <369@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: Deleted text... > > Contrary to your >insinuations, X3J3 has devoted a lot of time to trying to ensure that >this is the case. A subgroup (led by Mike Metcalf of CERN, I think), >did a complete reading of the two to check this. Of course, even >after very extensive testing there may be a bug, but somehow, I don't >think many people will think this is justification for dropping the project! 1. I don't believe I've ever said that the project should be dropped. If people want 8x, then they should have 8x. If people want 77, they should be able to have 77, without having all of 8x wrapped around it. That's what the debate is about. If the two are separate standards, both groups get what they claim they want. 2. Since you are an officer of X3J3, you should know who's the head of the subgroups (or be able to look it up in all the piles of mail that you get from the committee...). There's a major difference in my mind between "a complete reading of the two" and a direct comparison line by line to be sure nothing was changed. But, I have dropped out of this debate because I don't see that it's productive. X3 will determine the outcome at this point. They have not asked Walt, Bill, or me for our opinions on the subject. So, I will once again drop out of the debate.
khb@road.Sun.COM (Keith Bierman - Advanced Languages - Floating Point Group ) (09/09/89)
In article <BILL.89Sep7141011@hcx1.ssd.harris.com> bill@ssd.harris.com (Bill Leonard) writes: > >Note that this customer didn't care about portability: only that the >program behaves the same on the same hardware. Say all you want about >these features not having guaranteed portability between revisions of the >compiler -- Whizbang wouldn't change those things without a very good >reason, because they don't want to make their customers mad. What constitues good reason is highly variable. In former incarnations I have been bitten by most vendors, two of which are: 1) IBM (fortran G->H-VS fortran) all had some wonky differences 2) Cray cft114 -> cft77 These are the ones which come to mind first ... actually I can't recall any vendor who didn't screw me up on extensions at one time or another (if I used their computers long enough ... :>) ... usually it wasn't too major, and I learned how to write portable code ... :> Holding up standards activitity to protect those who wrote non-portable code, and whose vendors won't maintain the old features, and who don't want to cope seems to me as a user to be quite outrageous. (As a vendor I can see that _any_ change means folks might wander off to new platforms ... but that doesn't seem to be a good reason to freeze standards either ... standards exist to serve users & vendors ... so the good of the greatest number should be considered). Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
bill@ssd.harris.com (Bill Leonard) (09/12/89)
> You and Presley have been fussing about this for some time. > If there is some point to all this, I think the readers would like > to hear what it is. Sure, I'll try to make it as simple as I can: 1) The standard has undergone many, many changes over the last year. Text changes have been made wholesale, including some based on the so-called "Green Book" whose origins are clouded in the WG5 mist. 2) In that time, no one has (to my knowledge) made a concerted and detailed effort to ensure that all of FORTRAN-77 is included in FORTRAN/8x, and that there aren't any contradictions between the two. 3) There is no documentation to assist in maintaining the correlation, if any, between F77 and F8x; for instance, there is no cross-reference between the two. F8x uses entirely different language, different terminology, and in some cases uses the same terms used in F77 but with different meanings. I think that makes it very difficult for even X3J3 to reliably ensure that F77 is a true subset of F8x. > Contrary to your insinuations, X3J3 has devoted a lot of time to trying > to ensure that this is the case. A subgroup (led by Mike Metcalf of > CERN, I think), did a complete reading of the two to check this. Of > course, even after very extensive testing there may be a bug, but > somehow, I don't think many people will think this is justification for > dropping the project! This effort was done prior to the many changes made to the draft. Anyway, I never said it was justification for dropping the project -- I never said anything about dropping the project! Don't put words in my mouth! What I said was that this was justification for keeping FORTRAN/77, because it raises well-founded doubts as to whether F77 programs will still be standard-conforming under F8x. (Please note, however, that this is not the only justification.) I hope this is the last time I will have to correct misrepresentations of my statements. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (09/12/89)
In message <BILL.89Sep7141011@hcx1.ssd.harris.com> from bill@ssd.harris.com Bill Leonard concocted the following hypothetical: >... Let's say I have a >customer bidding for a government contract to provide a flight >simulator for the new F-1600 fighter jet, ... He's already >gotten an exception from DoD to use FORTRAN instead of Ada (this does >happen, by the way). ... >Note that [Bill's] customer didn't care about portability: >only that the program behaves the same on the same hardware. Hmm, can we conclude that for this application that either (1) FORTRAN is better; or (2) the Government doesn't care about portability; or (3) Reagan trickle-down theory is at work. Bill, please provide a 10-20 page explanation of why the government no longer considers FORTRAN an acceptable computer language. Please plot monthly statistics showing the percentage of exceptions granted by the government since ADA was adopted; include a projection into the future. Has anyone asked the government under what circumstances they would consider returning to a Fortran standard? Isn't there more economic incentive for persuading them to come back? Wouldn't a substantially improved Fortran help? Is FORTRAN best for Bill's customer? Flight simulation suggests the need for many real time features. Even a cursory examination of X3.9-1978 standard shows that no interface exists for real time applications. In message <BILL.89Aug7142959@hcx2.ssd.harris.com> from bill@ssd.harris.com, Bill Leonard writes: ... >Most vendor extensions are aimed at specialized markets >(e.g., real-time simulation, process control, etc.). I'd like to debate that point, but-- It seems that your justification for two FORTRAN standards depends on the existence of implementor extensions--especially real-time interface extensions. Perusing the list of available ANSI documents, I found the following item: "ISO 7846-1985, Industrial real-time FORTRAN--Application for the control of industrial processes, $39.00." Isn't that already a more standard standard! Since X3.9-1978 is without any standardized features for real-time applications, it surely is not suitable for flight simulation and should not exist as a stand-alone standard in order to legitimize a chaotic collection of implementor extensions. I believe that the group of "implementor extensions" should be empty! If there are to be extensions, they should be Official sanctioned extensions that you and others on the X3J3 committee have reviewed. Sections 1.3.2(4) and 1.4 as contained in the X3.9-1978 document are antithetical to the purpose described in section 1.1. In my view X3.9-1978 is not a standard--it is only a document that is more or less useful for the stated purpose. "The purpose of this standard is to promote portability of FORTRAN programs for use on a variety of data processing systems." As long as sections 1.3.2(4) and 1.4 remain in the document the standard is self-destructive (suicidal). ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
jerry@violet.berkeley.edu ( Jerry Berkman ) (09/13/89)
In article <608@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > >I believe that the group of "implementor extensions" should be >empty! If there are to be extensions, they should be Official >sanctioned extensions that you and others on the X3J3 committee >have reviewed. ... > >---------------------------------------------------------------------- >Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl >Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah >University of Maryland CoSy: ahybl >School of Medicine >Baltimore, MD 21201 Phone: (301) 328-7940 (Office) >---------------------------------------------------------------------- I assume from this that you think vendors supplying a "double complex" Type in Fortran 77 should be tarred and feathered! I am grateful for that extension on short word machines; I wish X3J3 had provided it. As it was, the initial implementations of double complex on different vendors systems used different names for the intrinsics. This was a minor mess, but better than no complex. Also, what about REAL*16 and INTEGER*2? There are some projects which could not function without those extensions. For that matter, I have been writting Fortran programs in lower case for 8-10 years, and don't feel any guilt about using that extension. I feel similarly about "z" format terms and "include" statements. On the Cray, my favorite timing tool is the "rtc()" intrinsic function; it is compiled into a single instruction which returns the time of day clock in machine cycles so that I can do very accurate timings of small loops. It's not portable, but I don't care. I would however, like a portable cpu time used subroutine or function. Fortran 8x does not include such a function in it's vast set of intrinsics; even though every system I use has such a function (I know there are probably some that don't; add it anyway to the standard and let them return zero all the time). My point is that there have been many useful extensions to the standard, and that there will continue to be useful extensions. We can't freeze Fortran. - Jerry Berkman, U.C. Berkeley
psmith@mozart.uucp (Presley Smith) (09/13/89)
In article <1989Sep13.001659.721@agate.berkeley.edu> jerry@violet.berkeley.edu ( Jerry Berkman ) writes: >In article <608@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: Text deleted... > >My point is that there have been many useful extensions to the standard, >and that there will continue to be useful extensions. We can't freeze >Fortran. Anyone who does believes that Fortran 8x will NOT be extended is naive. Vendors do listen to the users and extend languages when the user demand is there for an extension, whether that extension is standard or not.
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (09/13/89)
In message <1989Sep13.001659.721@agate.berkeley.edu> from jerry@violet.berkeley.edu, Jerry Berkman writes >I assume from this that you think vendors supplying "Satanic character aliases" >in Fortran 77 should be tarred and feathered! Actually, I favor the punishment inflicted upon Prometheus. I must defer to someone on the X3J3 committee to explain why they didn't provide for double complex, REAL*16 and INTEGER*2. >There are some projects which could not function without those variable types. Perhaps the X3J3 is too much dominated by the vendors and they didn't talk early enough and long enough with the real users. How much opportunity did you have to express you perceived need to the pre-1978 X3J3 committee? To the 1989 X3J3 committee? >For that matter, I have been writting Fortran programs in lower case >for 8-10 years, and don't feel any guilt about using that extension. >I feel similarly about "z" format terms and "include" statements. I use mixed case, c-language #include "filename" statements and in-line comments in my code. I pass my code through a vendor sensitive filter to produce fortran source appropriate for the target machine. I DO NOT need any implementor extensions. >On the Cray, my favorite timing tool is the "rtc()" intrinsic function; >... I can do very accurate timings of small loops. It's not portable; >I would however, like a portable cpu time used subroutine or function. >Fortran 8x does not include such a function ... >My point is that there have been many useful extensions to the >standard, and that there will continue to be useful extensions. A "rtc()" intrinsic function would be useful to vendors, users and especially to programmers writing benchmark programs. I have only one application where I need to extract the cpu time from the system. This kind of problem can be handled by collecting a small set of routines written in assembler or C that are specific for each different implementation. (The code for such routines are usually readily available.) On my 3B1/SVS, I wrote a CALL SYSGET('string') routine to provide for system calls. For example, to get cpu timing information I compile the following line into my code: Call sysget('ps -e|grep a[.].*|tr -s " "|cut -f4 -d" ">ps.time') Obviously, my timing problem is not crucial but, again, it shows that I didn't need an implementor extension. >We can't freeze Fortran. After our law makers write and pass laws, the laws appear in a publication of state or federal statutes. The legislature will try to correct a discovered flaw or ambiguity in a law during their next session. In rare cases, a special session may be called to tackle the problem. Ambiguities in the law can also be resolved by the courts. All new laws, recently revised laws and notes of court cases are placed in the "Cumulative Annual Pocket Part" which is placed in the back of the appropriate volume of the statutes. Clearly sections 1.3.2.(4) and part of section 1.4 in X3.9-1978 MUST be deleted! The standards making body should produce a "Cumulative Annual Pocket Part" that is published in FORTRAN forum and other appropriate media. There must be an adjudication mechanism. The standards organization must have a registered trademark for the FORTRAN Language. A Fortran Validation Suite must be created, updated and revised annually. Before a compiler is allowed to use the trademark, it must pass the validation tests. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
bill@ssd.harris.com (Bill Leonard) (09/14/89)
Dr. Hybl seems to have badly misunderstood my posting, so I'd like to clarify several things. First, let me say that my example was hypothetical, but not unrealistic. These kinds of bids are submitted routinely. > Hmm, can we conclude that for this application that either (1) FORTRAN > is better; or (2) the Government doesn't care about portability; > or (3) Reagan trickle-down theory is at work. None of the above. The customer is bidding based on his assumption that the Government cares about cost, and he thinks that making minor modifications to an existing program is much more cost-effective than developing from scratch using Ada. Most of the exceptions granted by DoD that I know about are based on the existence of something "close" to what the contract calls for. In my example, this previously-existing program was also developed for the Government, so apparently _it_ was portable enough for the Government. > Bill, please provide a 10-20 page explanation of why the government > no longer considers FORTRAN an acceptable computer language. I can't provide an explanation of something I don't believe is true. The Government still does an awful lot of work in FORTRAN; only the DoD is under any mandate to use Ada, and even they give exceptions. Yes, it is true that those exceptions are declining; it's anyone's guess where they'll go. But FORTRAN use by other Government agencies and contractors is still pretty strong. > Has anyone asked the government under what circumstances they would > consider returning to a Fortran standard? Isn't there more economic > incentive for persuading them to come back? Wouldn't a substantially > improved Fortran help? They never left. As for whether a "substantially improved" FORTRAN would help, help what?. I don't think DoD is going to back away from Ada, with or without F8x. As for whether existing use of FORTRAN within the Government would be "helped" by F8x, I merely note that several representatives of various U.S. Government agencies and contractors wrote public comments that opposed 8x. I believe that is justification for thinking they would prefer to use F77 than F8x. Somehow people keep tying the issue of retaining FORTRAN/77 with a rejection of FORTRAN/8x. The X3 vote says nothing about rejecting F8x. I've said numerous times in my arguments on this issue that those who want F8x may have it, but there is sufficient dissent among FORTRAN users that it seems prudent to retain F77 until either those dissenters are won over to F8x or they switch to some other language. If the use of F77 declines, as those who support F8x want us to believe will happen, then there will be no reason to reaffirm F77 five years from now. > It seems that your justification for two FORTRAN standards depends > on the existence of implementor extensions--especially real-time > interface extensions. Not at all. This particular customer's justification for bidding an existing FORTRAN application may well be based on those extensions, however. Since the Government saw fit to buy the original product, presumably those extensions were sufficiently portable (among the class of machines suitable for such real-time application) to satisfy its needs. Judging from user requests for real-time extensions, I'd say the ISO standard you cited was evidently not found to be sufficient for their needs. The Government continues to buy their products, so they must be doing something right! My justification for retaining F77 is based on the number of public comments opposed to F8x. If they don't like F8x, the only other choice we can provide them in the short term is F77 or another language entirely. I think retaining F77 is a reasonable choice. Finally, I'd like to point out (again) that portability is a relative concept. A flight simulator is different from, say, a finite-element analysis application, in that it has to deal with external hardware, it has to operate in a "hard" real-time environment, and it has tight performance requirements. Not all machines can meet these requirements, so portability to those machines is uninteresting. Still other machines are far too expensive for the task, so portability to those machines is uninteresting too. In this environment, one is interested only in portability among the machines that can serve the purpose. In many cases, the extensions to FORTRAN for this kind of real-time computing are common to all the vendors of those machines -- what more portability could you want? I'll readily agree that not everyone falls into this class of user, but that doesn't mean those users don't deserve fair treatment. If they say F8x is not suitable for their needs, who am I to argue with them? They spoke, and I listened. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (09/16/89)
>Dr. Hybl seems to have badly misunderstood my posting, so I'd like to >clarify several things. ... The customer is bidding based on his >assumption that the Government cares about cost, ... >Most of the exceptions granted by DoD that I know about are based >on the existence of something "close" to what the contract calls for. That sounds like the usual argument employed for awarding sole source contracts. Sole source contracts are often expensive and prone to hanky-panky. >The Government still does an awful lot of work in FORTRAN; ... ?^^^^^? Congress, always being interested in the cost of toilet seats and computer equipment (Automatic Data Processing Resources), identified that one cause of sole source acquisition was the existence of extensions in the various compilers. In House Report No. 94-1746 titled "Administration of Public Law 89-306, Procurement of ADP Resources by the Federal Government," we read: "This means that a user agency may adopt Cobol but employ unique features which will impede conversion." That was written in 1976. You can replace the word Cobol with Fortran, features with extensions and conversion with portage and notice that nothing has changed over the last thirteen years. The Brooks committee added: "Only when standard high level languages are developed and their use enforced will a barrier to effective competition be eliminated." They intended that the high level languages should be without extensions! >Finally, I'd like to point out (again) that portability is a relative >concept. Yes, it's extremely useful for users but a real-time pain for the vendors. Bill, a panegyrists for F77, refers to it in the singular as if there weren't thousands of disparate implementations. Hasn't he noticed that the VAX/VMS compiler already contains many of the F8x features? Although I don't think much of the barnacles attached to VMS, I don't see VAX being stoned for adding the F8x features. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
hirchert@uxe.cso.uiuc.edu (09/18/89)
Albert Hybl has been trying to convince the rest of us that the Fortran standard should prohibit extensions. I will gladly grant him that inappropriate use of vendor extensions is highly undesirable. I would like to suggest two things: 1. Many of us from time to time use Fortran to do things not intended to be portable or intended to be portable only through the wholeshale replace- ment of some processor-specific kernel functionalities. In such cases, it may be entirely appropriate to make use of vendor extensions. 2. Even if the standard prohibited extensions, it would be essentially meaningless. (More accurately, it would mean little more than the current FIPS switches.) Typically, a processor needs to be standard conforming only under one combinations of its switches. A vendor could argue along the lines "Our command to run the standard-conforming compiler is 'fortran -noextensions'. The command 'fortran' is our command to run the compiler for a language similar to standard fortran, but with a number of useful extensions." In other words, vendors will stop providing extensions only when there stops being a market for them. The best the standard can do is to provide the tools with which to write readable, portable, effcient, etc. programs; it can't force programmers to produce programs that actually have those properties. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
psmith@mozart.uucp (Presley Smith) (09/19/89)
In article <611@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > >Bill, a panegyrists for F77, refers to it in the singular >as if there weren't thousands of disparate implementations. >Hasn't he noticed that the VAX/VMS compiler already contains >many of the F8x features? Although I don't think much of the >barnacles attached to VMS, I don't see VAX being stoned for >adding the F8x features. Maybe someone would like to enlighten us as to what Fortran 8x features are in the VAX/VMS compilers... Do the VAX/VMS compilers contain: 1. Array notation 2. Interface 3. Overloading 4. Modules 5. Pointers 6. ??? If you count FORTRAN 77 that as contained in 8x, the VAX/VMS compilers certainly contain that. Things like structures are done differently in the VAX/VMS compilers to what the Fortran 8x standard defines for structures... etc. Would someone like to provide some examples of these "many" F8x features?
bill@ssd.harris.com (Bill Leonard) (09/20/89)
> I believe that the group of "implementor extensions" should be > empty! If there are to be extensions, they should be Official > sanctioned extensions that you and others on the X3J3 committee > have reviewed. Sections 1.3.2(4) and 1.4 as contained in the > X3.9-1978 document are antithetical to the purpose described in > section 1.1. I take it that you are opposed, then, to extensions even if they are implemented by several vendors? I'll take a big leap and assume that your reason is because code which uses those extensions is not portable among the entire set of FORTRAN processors. Am I right? Then I think you must also be opposed to the FORTRAN/8x standard, because of the CHARACTER KIND= facility. Why? Because there is no requirement in F8x on what KINDs of CHARACTER a processor must provide. I suspect that vendors who do business in China and Japan, for example, will implement KINDs for the Oriental character sets; vendors who don't do business there probably won't bother. Hence, code written using Kanji would not be universally portable. This seems to me the same situation that arises with vendor extensions. In fact, I fail to see how your proposal for "Officially Sanctioned" extensions solves the problem either. There would still (I presume) not be any requirement that EVERY vendor implement those extensions. So how does this improve the situation? X3J3 has often refused to standardize extensions on the grounds that they are not required by a large body of users. I think that is a perfectly valid reason; in my opinion, it has not been applied often enough to F8x features. Nevertheless, it seems unreasonable to me that a user with a particular need (for instance, real-time computing) should be denied the language facilities he needs, simply because they would not be universally portable. Moreover, if the vendors waited for X3J3 to define the "Officially Sanctioned" extensions our customers need, we'd be out of business, and probably so would our customers. The ANSI process, indeed any design done by committee, is far too slow to react to the fast pace at which computer technology changes. I think your proposal turns the process upside-down. Vendor extensions should be the "proving ground" for language evolution. Only when a language feature has proven to be: 1) implementable; 2) widely used; and 3) portable to at least some degree, should it be standardized. I have no objection to standardizing extensions, once they have proven to be useful, for those extensions that are used by a small segment of users. But I don't think the standardization should come first; first one must prove that the perceived need does in fact exist, and that there are no serious impediments to implementation. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (09/20/89)
In message <1805@convex.UUCP> from psmith@mozart.uucp, Presley Smith writes: >Maybe someone would like to enlighten us as to what Fortran 8x >features are in the VAX/VMS compilers... In message <MCCALPIN.89Sep3075933@masig3.ocean.fsu.edu> from mccalpin@masig3.ocean.fsu.edu, John D. McCalpin wrote: >In message <5272@garfield.MUN.EDU> chris2@garfield.MUN.EDU (Chris >Paulse) writes: >>I was recently sent some Fortran code which was written for >>VAX/VMS that included some extensions that made our bsd f77 >>compiler hiccup. The particular extensions that did this were >> o comments at the end of a line indicated as ... >> SOURCE GOES HERE ! this is a comment >> o the do/enddo construct >>Does there exist a preprocessor for this flavor of F77 which >>will easily convert it back to vanilla f77? > >My mailer couldn't find garfield.mun.edu, so here is a lex program >that should do the trick. --lex program deleted-- Well, there are two. Let us thank John for providing the lex program. It will allow me to consider using the DO...ENDDO syntax and still keep my 3B1/SVS compiler. I notice with some sadness that John used lex instead of fortran to encode the filter. It shows that fortran lacks character! I hope that F8x will be substantially enhanced in this area! I joined ACM _many_ year ago and subscribe to Fortran Forum in part because they had published draft language standards in their technical journals. In volume 8 number 3 (August 1989) of Fortran Forum, I read: "SIGPLAN has budgeted for continuing this practice of publishing draft Programming Language standards (either in SIGPLAN Notices or in news-letters such as Fortran Forum), as a service to its constituency." Until F8x is printed in Fortran Forum, I will be without a draft copy. Thanks to CBEMA that may be too late for me to contribute to the debate on what features should or should not be included. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
psmith@mozart.uucp (Presley Smith) (09/22/89)
In article <BILL.89Sep20094249@hcx3.ssd.harris.com> bill@ssd.harris.com (Bill Leonard) writes: <<<< Text Deleted >>>> > >I think your proposal turns the process upside-down. Vendor extensions >should be the "proving ground" for language evolution. Only when a >language feature has proven to be: 1) implementable; 2) widely used; and 3) >portable to at least some degree, should it be standardized. I have no >objection to standardizing extensions, once they have proven to be useful, >for those extensions that are used by a small segment of users. But I >don't think the standardization should come first; first one must prove >that the perceived need does in fact exist, and that there are no serious >impediments to implementation. >-- If only X3J3 had adopted that philosophy in Fortran 8x instead of refusing to standardize existing practice and producing different syntax and semantics just so it would be different. Oh well, great idea. Maybe in Fortran 9x.