jlg@lanl.gov (Jim Giles) (02/12/91)
From article <7797@exodus.Eng.Sun.COM>, by wsb@boise.Eng.Sun.COM (Walt Brainerd): > [...] > [What are you going to call the next version--"Fortran Extended Extended"?] Well, I don't know if there's much hope, but I'd like "Fortran yy" (with 'yy' designating year numbers) to always refer to the Fortran programming language and not to this thing X3J3 has recently put together. So, maybe we could get a Fortran 95 (based on Fortran 77 with the standardization of common vendor extensions - in other words, standardize common practice). I know. Walt will jump all over this suggestion. This is the only article I will submit on this subject as I don't want to get into the same argument yet again. J. Giles
wsb@boise.Eng.Sun.COM (Walt Brainerd) (02/12/91)
In article <14244@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > > Well, I don't know if there's much hope, but I'd like "Fortran yy" > (with 'yy' designating year numbers) to always refer to the Fortran > programming language and not to this thing X3J3 has recently put > together. So, maybe we could get a Fortran 95 (based on Fortran 77 > with the standardization of common vendor extensions - in other words, > standardize common practice). > "This thing X3J3 put together" is also what almost the entire world (including the USA) has voted to be "the Fortran programming language". Thus it is logically impossible to achieve what Jim likes. Fortunately or unfortunately, calling it something else will not make it go away. And incidentally, one of the important features of the ANSI/X3 plan when proposing the name "Fortran Extended" and keeping Fortran 77 as a standard is that, under no circumstances, is anyone to propose extending Fortran 77 (we'll see if they can stick to it). And I also thought data structures, recursion, array processing, DO ENDDO, namelist, include, and the bit intrinsic functions (to name a few important new features in Fortran 90) were common vendor extensions. Of course, there are some, like modules, that are not. If we stuck to this philosophy, there would be no character data type or IF-THEN-ELSE in Fortran 77 because these were not common vendor extensions in the early '70s. Would Fortran 77 be a better language without these two features? > I know. Walt will jump all over this suggestion. This is the only > article I will submit on this subject as I don't want to get into > the same argument yet again. > > J. Giles Before I jump too hard, I would like to understand. I am not sure what the "same argument" refers to, but sometime soon, people will be proposing the beginning of development of Fortran 2000 (or whatever), so this is the time to start discussing the fundamental philosophical and technical questions, not in 2001 when it's all over again. So I think there should be lots of "arguments" about this from anybody that is interested. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
hirchert@ncsa.uiuc.edu (Kurt Hirchert) (02/12/91)
In article <14244@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Well, I don't know if there's much hope, but I'd like "Fortran yy" >(with 'yy' designating year numbers) to always refer to the Fortran >programming language and not to this thing X3J3 has recently put >together. So, maybe we could get a Fortran 95 (based on Fortran 77 >with the standardization of common vendor extensions - in other words, >standardize common practice). But that would be contrary to common practice! :-) Seriously, this is a matter of persepective. When FORTRAN 77 was adopted, many of the features it introduced were already common practice, but many others were not. Fortran 90 similarly includes both new features that are already common practice and those that are not. Unquestionably, the balance between these classes of features is different, and the sources of the features span a much wider field, but a standard that did nothing but ratify common practice would be a throwback to the original 1966 FORTRAN standard. Your "Fortran 95" sounds like a subset of Fortran 90; the _common_ vendor extensions I am aware of are advance implementations of Fortran 90 features or outgrowths of FORTRAN 77 or Mil. Std. 1753 that have been incorporated into Fortran 90. "Fortran 95" wouldn't do much to improve my programming environment (because those features are already common). Fortran 90 has the potential to make significant improvements if it is decently implemented. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/12/91)
...description of what future standards work should be, was, etc....
I think we should aim for two goals:
1) five years out, we should have a compendum of technical
fixes, adjudications, etc. to cement "f90"
2) ten years out, we should have the next incremental changes.
we should try to hold the dates, and slip the functionality this time;
delaying the document doesn't seem to improve its quality, nor to
settle the differences between the various parties.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043lamson@el1.crd.ge.com (scott h lamson) (02/12/91)
In article <7822@exodus.Eng.Sun.COM> wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: > From: wsb@boise.Eng.Sun.COM (Walt Brainerd) > ..., but sometime > soon, people will be proposing the beginning of development > of Fortran 2000 (or whatever), so this is the time to start > discussing the fundamental philosophical and technical questions, > not in 2001 when it's all over again. In addition to starting speculations on Fortran 2000, I think it would be very useful to have some mechanism being put into place to standardize "modules" as they are developed, to avoid the F-77 situation where sparse matrix code is so difficult to share as most developers reinvent a sparse matrix data structure just enough incompatible with others that routines cannot be readily shared. -- Scott| ARPA: lamson@crd.ge.com Lamson| UUCP: uunet!crd.ge.com!lamson (518)387-5795| UUCP: uunet!sierra.crd.ge.com!lamson General Electric Corporate Research and Development
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/12/91)
In article <LAMSON.91Feb11200000@el1.crd.ge.com> lamson@el1.crd.ge.com (scott h lamson) writes:
..
In addition to starting speculations on Fortran 2000, I think it would
be very useful to have some mechanism being put into place to
standardize "modules" as they are developed, to avoid the F-77
..
Modules can (and I think should) be standardized by those closest to
the particular problems.
There is already a "string" module which is being proposed as a
standard, I think it is going BSI or ISO ... but I don't recall
offhand.
There is no reason why IEEE, ANSI, BSI and others can't all play in
this ballpark. Of course, as usual the proposals for work should be
circulated in the standards community to avoid duplication of effort.
But unlike the language standard itself, there is no reason to limit
the process to one organization.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043john@ghostwheel.unm.edu (John Prentice) (02/12/91)
Before we get too busy inventing Fortran Extended Extended (over-extended?), let me just point out that we don't even have compilers yet for the "old" new standard (i.e., Fortran Extended) :-) ! John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (02/12/91)
In article <1991Feb12.055337.25661@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: >Before we get too busy inventing Fortran Extended Extended (over-extended?), >let me just point out that we don't even have compilers yet for the "old" new >standard (i.e., Fortran Extended) :-) ! > It is one thing to design a language 'on paper' or 'in committee'. It is quite another to adopt, support and USE it in practice. Many people who post to this group seem aware of extensions and extended-extensions to Fortran '90. However, I can't help but wonder if the 'new' version will fall into to the same abyss that the '77 version did. With each push for yet another extension, an adopted, debugged and universally IMPLEMENTED version seems further away... Over the last decade, the gap between what version of Fortran was being taught in universities and used in industry has increased. A large reason for this was the constant state of 'flux' Fortran seems to have been in since 77. Is this a cycle that must be repeated? -- John L. Bradberry |Georgia Tech Research Inst|001100110011001100110011 Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'
chidsey@smoke.brl.mil (Irving Chidsey) (02/12/91)
In article <21844@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) writes: <In article <1991Feb12.055337.25661@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: <>Before we get too busy inventing Fortran Extended Extended (over-extended?), <>let me just point out that we don't even have compilers yet for the "old" new <>standard (i.e., Fortran Extended) :-) ! < <It is one thing to design a language 'on paper' or 'in <committee'. It is quite another to adopt, support and USE it in <practice. Many people who post to this group seem aware of <extensions and extended-extensions to Fortran '90. However, I <can't help but wonder if the 'new' version will fall into to the <same abyss that the '77 version did. With each push for yet <another extension, an adopted, debugged and universally <IMPLEMENTED version seems further away... < <Over the last decade, the gap between what version of Fortran was <being taught in universities and used in industry has increased. <A large reason for this was the constant state of 'flux' Fortran <seems to have been in since 77. Is this a cycle that must be <repeated? < <John L. Bradberry |Georgia Tech Research Inst|001100110011001100110011 <Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism <2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. How about biting off manageable chunks? Taking smaller steps every 5 years instead of a humongous leap every 10-12 years. That would be more attuned to the rate at which extensions are adopted, and the different suppliers wouldn't diverge as much. The name should obviously be Fortran Extended ** 2. Irv -- I do not have signature authority. I am not authorized to sign anything. I am not authorized to commit the BRL, the DOA, the DOD, or the US Government to anything, not even by implication. Irving L. Chidsey <chidsey@brl.mil>
wsb@boise.Eng.Sun.COM (Walt Brainerd) (02/13/91)
In article <LAMSON.91Feb11200000@el1.crd.ge.com>, lamson@el1.crd.ge.com (scott h lamson) writes: > > In addition to starting speculations on Fortran 2000, I think it would > be very useful to have some mechanism being put into place to > standardize "modules" as they are developed, to avoid the F-77 > situation where sparse matrix code is so difficult to share as most > developers reinvent a sparse matrix data structure just enough > incompatible with others that routines cannot be readily shared. > We are starting to get some great constructive ideas. Those of us pushing for adoption of modules in Fortran 90 thought this is exactly the way they should be used. We thought perhaps some modules could be standardized at the same time as Fortran 90, but we spent most of the last 5 years fighting off people who wanted to eliminate modules, rather than spending the time developing a few standard modules. Irving Chidsey said we should have smaller revisions in less time. One way to accomplish this is through standardized modules. Anyone can propose a standard module and it does not have to accompany a revision of Fortran, as Keith Bierman pointed out, so we could have a sparse matrix module just as soon as folks can do the work! As another example, I think most, if not all, of the POSIX .9 Fortran binding could be done as a Fortran 90 module. Other things, like a "parallel Fortran" probably can't be done this way, but such things might be accomplished in less than 10-12 years if the appropriate things are done with modules. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991