PDM1881%mvs.draper.com@RELAY.CS.NET (10/24/89)
> > > This vote is good news for the ENTIRE FORTRAN community. > > PRESLEY, YOU CANNOT BE SERIOUS! It is an unmitigated disaster. > I agree with both sides!!! Clearly, it is in everyone's best interest to have a single standard. The problem is that X3J3 has done a terrible job. First they spent several years cooking up a strange brew. Then when we finally figured out what they had done, they didn't listen to our complaints. (Because the previous X3J3 did such a superlative job on FORTRAN 77, we were complacent during the early years of the new committee. How many people even considered that it was a new committee?) As I read it, WG5 is desperate for a new standard and will make do with Fortran 8x. Some of us in the U.S. want the right standard. It is my hope that Fortran 8x will be defeated and will not become an ANSI standard. Yes, it is truly unfortunate that ISO is going the other way. As I understand it, there is dissention in the European community as well, if not in WG5 votes, so there may be some hope. As a long time member of the SHARE FORTRAN Project, I personally urged that X3 retain the FORTRAN 77 standard. My intent remains one standard. I wish to reject Fortran 8x, even if it is adopted, and it appears likely that 8x will be adopted in the face of major objections. What else can I do? X3J3 has consistently refused to make the kind of sweeping changes to 8x which are required. Their small simplifications have been largely cancelled by recent additions. I feel it is likely that a majority of FORTRAN programmers in the U.S. do not want 8x. The vast majority at my company certainly don't want it. Should I meekly go along? Ultimately, all I get to say is yes or no. I say no. Standards are supposed to "codify existing practice." FORTRAN 77 clearly did that, when it was approved. Fortran 8x just as clearly does not. It contains two or three times as many changes as it should. 8x makes fundamental changes in how the language should be used. Keep in mind that a significant number of active FORTRAN programmers do not know the correct IF-THEN-ELSE-ENDIF syntax of FORTRAN 77 well enough to use it regularly. Fortran 8x is far too complicated. It will require new tools - compilers, debuggers, analyzers - rather than improvements to existing tools. Why should we pay for them? Here is a cursory list of features which should be considered for removal: * MODULE-USE. A decent INCLUDE is what we really need. * The gratuitous change from CHARACTER*n to CHARACTER (LEN=n). Also, the double colon (::). * The KIND parameter. - Use a new data type such as GRAPHIC for double byte characters. - Define a minimum precision for REAL such as 10 decimal digits. This would propagate the change to existing code. Instructions to the processor may specify a different precision for REAL and DOUBLE PRECISION, primarily to allow old programs to function without change. * Internal procedures. * Masked array assignment. * Vector subscripts. * Pointers. The proposed standardization of INCLUDE is useless. It has clearly been written to silence those who clamored for it, without an attempt to provide a portable tool. The authors clearly want MODULE-USE to be employed and INCLUDE to be avoided. The current definition of "INCLUDE line" is processor dependent in the source code. Some people like that, but it must be extended to the "INCLUDE statement": INCLUDE '(lib-name)' "lib-name" is a Fortran name of 6 characters or less (the processor is permitted to allow longer names). The processor must support instructions independent of the source program defining where all referenced source text resides. It is intended that these instructions define one or more libraries or directories to be searched according to known rules for each "lib-name". This form is required to provide a portable, standard, INCLUDE facility. X3J3 should have defined full FORTRAN 77 as the subset for the new standard, and provided it on the left side of facing pages. BNF is OK, so long as it is used for both, so that comparisons can easily be made. Pete Matthews, Jr. C. S. Draper Lab. (My own opinions, of course.)
ggw@wolves.uucp (Gregory G. Woodbury) (10/27/89)
In article <7485@xenna.Xylogics.COM> PDM1881%mvs.draper.com@RELAY.CS.NET writes: >> >> > This vote is good news for the ENTIRE FORTRAN community. >> >> PRESLEY, YOU CANNOT BE SERIOUS! It is an unmitigated disaster. > Actually, the maintenance of the F77 standard as "official" is good news here. I have had a long fight to get one of our main theoretical people to "adopt" f77 for use. The only way this was finally forced was that he was migrated (forceably ;-) to a machine that didn't support some of the old FORTRAN II/IV features! I finally got a look at the F8x stuff -- what is this language? > >What else can I do? X3J3 has consistently refused to make the kind of >sweeping changes to 8x which are required. Their small simplifications >have been largely cancelled by recent additions. I feel it is likely >that a majority of FORTRAN programmers in the U.S. do not want 8x. The >vast majority at my company certainly don't want it. Should I meekly go >along? Ultimately, all I get to say is yes or no. I say no. HEAR HEAR! The language defined by F8x is not just a simple expansion of the capabilities of f77. In order to use the new features that let one get more performance out of the hardware one has to RE-LEARN the language! I am positive that there would be NO way to get the person I mentioned above to adopt F8x -- he'd probably quit first! > >[Keep in] >mind that a significant number of active FORTRAN programmers do not know >the correct IF-THEN-ELSE-ENDIF syntax of FORTRAN 77 well enough to use >it regularly. > But, it fits in smoothly with the previous versions of FORTRAN. And the previous methods still work as originally defined. >The proposed standardization of INCLUDE is useless. It has clearly been >written to silence those who clamored for it, without an attempt to >provide a portable tool. The authors clearly want MODULE-USE to be >employed and INCLUDE to be avoided. > So much for "formalizing existing coding practice". Practically all of the f77 compilers that I have seen allow some form of include, or you can preprocess the program source yourself before compilation. The purpose of a standard it to make it easy to have the same code compile and run on different platforms without having to be too concerned with the details of specific implementations. Some days you can't win for loseing. -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ] <standard disclaimers apply>