psmith@mozart.uucp (Presley Smith) (10/19/89)
The X3 committee voted today by a large margin to retain ANSI X3.9-1978, the current FORTRAN 77 standard, as an active standard of the American National Standards Institute (ANSI) and to make the proposed Fortran 8x a separate standard. This means that when Fortran 8x is finally approved that it will be assigned a different ANSI standard number. The proposed 8x standard is now being referred to as Fortran Extended. The effect of this action is that in the United States, FORTRAN users will have a choice between continuing to use FORTRAN 77 or moving to the new Fortran Extended products as they become available in the marketplace. FORTRAN 77 will continue to be an active ANSI Fortran Project so that interpretations may continue to be made on that standard by X3J3, but no major updates to that standard are anticipated. There was much discussion of the international implications of this vote. Internationally, the Fortran Extended standard will be the SAME as the ANSI Fortran Extended standard. This is in compliance with the October, 1988 directive of X3 that X3J3 produce a single standard for both domestic and international use. If the International Standards Organization (ISO) so chooses, FORTRAN 77 could be retained as a separate ISO standard also. That decision will be made by ISO at some future time. This vote is good news for the ENTIRE FORTRAN community. The more conservative FORTRAN user community has been concerned about true upward compatibility of their FORTRAN 77 code, potential performance issues in Fortran Extended, and other concerns about being forced to migrate to Fortran Extended. In effect, those users who wish to can continue to use FORTRAN 77 and can do so with ANSI standard compliant compilers. Users who want modern Fortran features will have those available in Fortran Extended products of the future. The entire Fortran community will benefit greatly from this decision made today by the X3 committee.
brainerd@unmvax.unm.edu (Walt Brainerd) (10/20/89)
In article <2192@convex.UUCP>, psmith@mozart.uucp (Presley Smith) writes: > > The X3 committee voted today by a large margin to retain ANSI X3.9-1978, > the current FORTRAN 77 standard, as an active standard of the American > National Standards Institute (ANSI) and to make the proposed Fortran 8x a > separate standard. > > This vote is good news for the ENTIRE FORTRAN community. It is nice to have Papa Presley tell us what is good for us; I guess we must assume that the majority of X3J3 (including most members representing users) didn't realize this previously when they voted consistently against two standards in any form and even against any sort of subsetting. This vote will have many effects that could be _disastrous_ for the ENTIRE Fortran community. The reasons have been elaborated previously on this news, but the most serious may be that the US appears to have told the world that we are no longer interested in cooperating with them in producing a Fortran standard. Another symptom of the economic decline of the US, it seems to me. It amazes me that people who claim to be experts in the business of computing (or any other, for that matter) can formally vote to change the basic goals and design specs of a project that is in a final testing phase and believe that the product produced is consistent with the new goals and specs. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
lamson@sierra.steinmetz.ge.com (scott h lamson) (10/20/89)
> Walt Brainerd: >This vote will have many effects that could be _disastrous_ for the >ENTIRE Fortran community. I agree, except that before too long, there will not ONE recognizable Fortran community. There will be two seperate communities. Are all the people who voted for retaining Fortran-77 going to resign from X3J3 so we get on with 8x? (after all, f-77 is not subject to further change, so why stick around?) >It amazes me that people who claim to be experts >in the business of computing (or any other, for that matter) can formally >vote to change the basic goals and design specs of a project that is >in a final testing phase and believe that the product produced is consistent >with the new goals and specs. OK, so as long as this has happened, what is the best course to pursue now? What can we choose for goals under the altered circumstances. With all the reactionaries clinging to Fortran-77 forever, what can we do with Fortran-x not having to comprimise to keep everyone together? It has been too long waiting for a revised standard to undertake new initiatives at this point. But we could reconsider some things removed from the first draft standard in the spirit of comprimise. I would like to see parameterized derived types first, with perhaps limiting this to non-precision parameters. This would be useful for defining matrices as derived types, especially sparse or symmetric arrays of size n by n. Should we reconsider removing the depracated features sooner? And provide only the new source form, with a requirement that the processor include a filter to convert the old source form to the new source form. > ?? remember writing this Presley ?? > Then your favorite vendor >will be put in a position of which standard to implement and >FORTRAN could go the way of other languages that have gotten >into similar situations. >That could result in a real MESS! So, stay tuned for more >information from the WG5 meeting in Paris... The future >of FORTRAN may be being decided this week... -- Scott| ARPA: lamson@crd.ge.com Lamson| UUCP: uunet!crd.ge.com!lamson (518)387-5795| UUCP: uunet!sierra.crd.ge.com!lamson
corbett@ernie.Berkeley.EDU (Robert Corbett) (10/20/89)
In article <LAMSON.89Oct19231922@sierra.steinmetz.ge.com> lamson@sierra.steinmetz.ge.com (scott h lamson) writes: >With all the reactionaries clinging to Fortran-77 forever, what can we do >with Fortran-x not having to comprimise to keep everyone together? > >It has been too long waiting for a revised standard to undertake new >initiatives at this point. But we could reconsider some things removed >from the first draft standard in the spirit of comprimise. I would >like to see parameterized derived types first, with perhaps limiting >this to non-precision parameters. Let's not forget to put back the world's most complex exception-handling scheme. BTW ,what ever happened to the features for interfacing with a CODASYL database? Surely they should be reinstated. How about adding features for parallel processing, object-oriented programming, real-time programming, artificial intelligence, OLTP, networked programming, etc. Yes, now that we don't have to worry about those reactionaries, we can turn Fortran into one heck of a language. Bob Corbett corbett@berkeley.edu
mccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin) (10/20/89)
In article <426@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >This vote will have many effects that could be _disastrous_ for the >ENTIRE Fortran community. The reasons have been elaborated previously >on this news, but the most serious may be that the US appears to have >told the world that we are no longer interested in cooperating with them >in producing a Fortran standard. Another way to look at this is to say that the committee is not interested in replacing a language that works with a language that has not even been implemented yet, until the new language proves itself in the field. I got the impression from Presley's message that the extended Fortran standard will still be a joint ANSI/ISO standard. Is this incorrect? >Another symptom of the economic decline >of the US, it seems to me. It amazes me that people who claim to be experts >in the business of computing (or any other, for that matter) can formally >vote to change the basic goals and design specs of a project that is >in a final testing phase and believe that the product produced is consistent >with the new goals and specs. I think it is fascinating that you think that this language is in the "final testing phase", when the language has never even been implemented! It would be far more accurate to say that the language is in the final _specification_ phase. I *like* the new programming language contained in Fortran-8X (though I would rather have an adaptation of this language without the need for FORTRAN-77 compatibility --- maybe Modula-2 + Fortran-8X extensions!), and if I had a working compiler I would switch to it right away to see whether it was worthwhile or not. But I think that this language will have to prove itself in the marketplace before it replaces FORTRAN-77 for everyone.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu
brainerd@unmvax.unm.edu (Walt Brainerd) (10/20/89)
In article <LAMSON.89Oct19231922@sierra.steinmetz.ge.com>, lamson@sierra.steinmetz.ge.com (scott h lamson) writes: > > It has been too long waiting for a revised standard to undertake new > initiatives at this point. But we could reconsider some things removed > from the first draft standard in the spirit of comprimise. I would > like to see parameterized derived types first, with perhaps limiting > this to non-precision parameters. This would be useful for defining > matrices as derived types, especially sparse or symmetric arrays of > size n by n. Should we reconsider removing the depracated features > sooner? And provide only the new source form, with a requirement that > the processor include a filter to convert the old source form to the > new source form. > These are thoughts that occur to me also upon hearing about the X3 vote. At the WG5 meeting last summer, preliminary proposals were made to fix many of these things (also such things as the "user-defined" character set and structures in common), but were not passed in the spirit of trying to compromise with X3J3 and get the job done. Most of the rest of the world feels stronly about these topics and surely would like to make them right again. However, this must be balanced against the possibility of further delay and removing the possibility that at least one of the US standards might match the ISO standard. These ideas need further exploration and discussion. -- 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) (10/20/89)
In article <32026@ucbvax.BERKELEY.EDU>, corbett@ernie.Berkeley.EDU (Robert Corbett) writes: > Let's not forget to put back the world's most complex exception-handling > scheme. BTW ,what ever happened to the features for interfacing with a > CODASYL database? Surely they should be reinstated. How about adding > features for parallel processing, object-oriented programming, real-time > programming, artificial intelligence, OLTP, networked programming, etc. > Yes, now that we don't have to worry about those reactionaries, we can turn > Fortran into one heck of a language. > This shows a complete misunderstanding of what has happened and what was proposed. Most of the "compromises" put in to appease the "reactionaries" have complicated the language considerably. Most of the things wanted by WG5 are simplifications. For example: removal of namelist I/O, structures in common, user-defined characters sets, etc. WG5 did request addition of pointers, but so did a large number of American commentors; and it replaced RANGE and identify, which were at least as complicated. Perhaps the addition of parameterized data types could be considered a complication, but it certainly is a simplification from the point of view of the user. -- 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) (10/20/89)
In article <MCCALPIN.89Oct20065314@masig3.masig3.ocean.fsu.edu>, mccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin) writes: > > Another way to look at this is to say that the committee is not > interested in replacing a language that works with a language that has > not even been implemented yet, until the new language proves itself in > the field. > In the usual case, a programming language standard has never been implemented. Depending on the language, various parts of it have been implemented, so one can only argue about how much of it has not been proven. In the case of the proposed 8x, a very large part (Fortran 77) has been implemented widely and most of the other features have been implemented as vendor extensions or in other languages. > I got the impression from Presley's message that the extended Fortran > standard will still be a joint ANSI/ISO standard. Is this incorrect? > Yes, essentially. As a member of ISO, ANSI can adopt an ISO standard; ANSI also can adopt additional or different standards. The recent X3 vote says they want Fortran 77 to be an additional standard (it is unlikely that ISO will retain it as a standard). There are still several steps to be taken before it is certain that there will be a common ANSI and ISO Fortran standard. Another sense in which they are joint is that ISO asked ANSI (X3J3) to develop _an_ ISO Fortran standard. I doubt they will ever do that again. > > . . . It amazes me that people who claim to be experts > >in the business of computing (or any other, for that matter) can formally > >vote to change the basic goals and design specs of a project that is ^^^^^^^ > >in a final testing phase and believe that the product produced is consistent > >with the new goals and specs. > > I think it is fascinating that you think that this language is in the > "final testing phase", when the language has never even been > implemented! It would be far more accurate to say that the language > is in the final _specification_ phase. > Sorry to eliminate your fascination, but I don't think that. ANSI/X3 can control only the standardization of the language, not its implementation. So the "project" refers to standardization. The project for which X3 is revising goals is in its final "testing" phase, i.e., the public review. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (10/21/89)
In article <MCCALPIN.89Oct20065314@masig3.masig3.ocean.fsu.edu> mccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin) writes: > >I got the impression from Presley's message that the extended Fortran >standard will still be a joint ANSI/ISO standard. Is this incorrect? Yes it is incorrect. I have asked permisson to forward comments from the ISO mailing list. When permission arrives.... The short answer is that ISO has basically accepted the draft (modulo edits) and the US has backed away from it. Furthermore ISO had voted near unimaously against subsetting with only 1 abstaintion (the US). It is too late in the standardization process to radically alter the document for ISO's purposes. There is little point in crafting up major mods to f8x "now that the luddites are gone", let's finish up in the international arena and build some compilers ... before we start on the next rev of the language. 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" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks
hirchert@uxe.cso.uiuc.edu (10/21/89)
It should be obvious by now that many of us do not share Presley's enthusiasm for X3's action. For me, the issue is _not_ the retention of FORTRAN 77 as a standard. Although I believe that action to be unfortunate, I do not share the alarmist view that it is a disaster. Because FORTRAN 77 will not be continued as an ISO standard, vendors wishing to compete in world markets will still have to implement Fortran 8x. Thus, IBM, DEC, and the other big vendors are all likely to have Fortran 8x available. In fact, because maintaining multiple compilers can be expensive, it is likely that their Fortran 8x compiler will also be their FORTRAN 77 compiler. Thus, Fortran 8x compilers are likely to be widely available. As people start writing programs using Fortran 8x features, users whose vendors don't implement Fortran 8x are going to find that they will have difficulty porting these programs to their machines. This will generate customer dissatisfaction. Ultimately, this will force these vendors to also implement Fortran 8x. In other words, the retension of FORTRAN 77 may delay the time that some vendors find it necessary to implement Fortran 8x, but vendors who assume that they will never have to do so are probably committing marketing suicide. The disaster is in the _way_ that X3 has chosen to retain FORTRAN 77. Proponents of this action have suggested that this should not cause problems in the international community. Considering the uproar it has already caused, this view must be regarded as self-delusion. Perhaps X3 can convince the international community that the fact that X3J3 is no longer charged with producing a revision of FORTRAN 77 doesn't really mean that they have repudiated their commitment to produce one for ISO, but that is by no means certain. Why did X3 choose to gamble? Even if the political issues can be resolved, the fact that ANSI Fortran is _drastically_ different from ISO Fortran and that it is ANSI Fortran Extended that corresponds to ISO Fortran is likely to be the source of many headaches. (The fact that many vendors already call their product Fortran Extended isn't going to help, either.) I certainly wouldn't recommend that X3J3 make an major changes in the technical content of Fortran 8x as a result of this action. It already has enough problems: . How do you modify the document so that nowhere in its approximately 300 pages does it indicate whether the name of the language it is defining is Fortran or Fortran Extended? (So that only the document title would differ between ANSI Fortran Extended and ISO Fortran) . How do you modify all the material that compares FORTRAN 77 and Fortran 8x rules and features so that there is never an indication of whether Fortran 8x supercedes FORTRAN 77 or supplements FORTRAN 77? (Since those relations will be different for ISO and ANSI) . How do you get all the above done in a timely fashion? (ISO is already annoyed at all the delays ANSI has caused. This time, ISO might just give up on ANSI and go write its own standard. If none of the ANSI standards ended up corresponding to ISO Fortran, that _would_ be a disaster!) Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
jlg@lanl.gov (Jim Giles) (10/21/89)
From article <428@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > [...] WG5 did request addition of > pointers, but so did a large number of American commentors; and it replaced > RANGE and identify, which were at least as complicated. [...] Pointers do _not_ replace RANGE and IDENTIFY. I remember someone on the committee announcing that they would never make the claim that pointers were a replacement of those features. In any case, pointers don't provide all the functionality of IDENTIFY. Pointers are more hazardous than either of the former features. And pointers are 'at least' as complicated as the former features - not vice-versa. Also, I suspect that all the public comment which asked for recursive data structures was lumped into that "large number of American commentors" that asked for pointers. I know I was - I foolishly mentioned pointers as a possible implementation strategy for recursive structures. If I had known what the committee would do with pointers, I wouldn't have mentioned them at all. I would rather do without recursive structures that have the language contaminated with the current pointer proposal.
brainerd@unmvax.unm.edu (Walt Brainerd) (10/21/89)
In article <14101@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <428@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > > [...] WG5 did request addition of > > pointers, but so did a large number of American commentors; and it replaced > > RANGE and identify, which were at least as complicated. [...] > > Pointers do _not_ replace RANGE and IDENTIFY. I apologize; I should anticipate these reactions more readily and be a bit a bit more specific. The only thing being discussed was complexity. Range and identify were taken out and pointers put in. In terms of total complexity, at least there was not a large increase; that is the sense in which pointers replaced range and identify. Of course, some of the functionality of range can be done with pointers, but I do not want to argue about which is better again at this time (unless others want to). -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
maine@elxsi.dfrf.nasa.gov (Richard Maine) (10/24/89)
In article <50500158@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes: > It should be obvious by now that many of us do not share Presley's > enthusiasm for X3's action. I'm another user that's sure not fond of the X3 action, and of Preseley's generally negative attitude about Fortran 8x as a whole. I might add that next time Presley claims to speak for all his customers that we have at least talked to Convex about becoming one of his customers and yes, I asked some very pointed questions about 8x compiler plans, etc. So I can guarantee that at least one of Presley's potential customers is highly interested and has asked about it. The general response I got struck me as them trying to tell me that F8X was going to cause me problems and I didn't really want it. Perhaps Presley's perception of customer desires reflects more what he wants to hear than what they actually say? Yes, that statement is unfairly harsh and probably untrue. It may well be that a majority of the customers agree with Presley. I don't take poll samples so I can't really speak for what the percentages are. All I can say for sure is that there is at least one of my viewpoint. The usual disclaimers apply. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.1.1]