mcdonald@uxe.cso.uiuc.edu (11/11/87)
Considering the enormous number of comments and flames about ANSI C in comp.lang.c, I am surprised to see no flames here about F8X. I'd like to see comp.lang.fortran as full of comments. I like some features about the draft (e.g. more control structures), but consider most of the changes a horrible perversion of Fortran, particularly the list of "deprecated features". It also seems to lack obvious extensions which have been around for years, for example, allowing both numbers and characters in the same common block. Doug McDonald
ags@j.cc.purdue.edu (Dave Seaman) (11/13/87)
In article <50500015@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >[The 8X standard] also seems to lack obvious extensions which have been around >for years, for example, allowing both numbers and characters in the same common >block. Common blocks will no longer be needed. Why burden implementors with something that is unnecessary? Why encourage users to stick to outmoded features of the language? -- Dave Seaman ags@j.cc.purdue.edu
mcdonald@uxe.cso.uiuc.edu (11/14/87)
>/* Written 8:29 am Nov 13, 1987 by ags@j.cc.purdue.edu in uxe.cso.uiuc.edu:comp.lang.fortran */ >Common blocks will no longer be needed. Why burden implementors with >something that is unnecessary? Why encourage users to stick to outmoded >features of the language? >-- >Dave Seaman >ags@j.cc.purdue.edu >/* End of text from uxe.cso.uiuc.edu:comp.lang.fortran */ Common blocks are the standard way of allocating global memory in Fortran, and have been since the 1950's. I don't see them as unnecessary. If they are removed, about 90% of all the Fortran programs I now use will break. I simply don't understand why they are "no longer needed". If I feed a Fortran program , which now compiles and runs correctly , to a compiler which omit common blocks, how is it going to work? I see it as a absolute , unchangeble, immutable fact: any legal Fortran program I now have MUST compile and run correctly on any Fortran compiler I pay for in the future. If it doesn't, that compiler is broken, and I will damn sure get my money back. It's OK to add features to a language, but never, ever, under any circumstances, remove them. Fortran 77 was bad enough, with the minor difficulty caused by removing Holleriths from some compilers. The proposed F8x is far worse. Perhaps someone will explain how my present programs will work without common, if they now use it? Will you volunteer to conver all my old programs to F8X or C. If you won't do the job for me, why not? Doug McDonald
rick@svedberg.bcm.tmc.edu (Richard H. Miller) (11/14/87)
In article <5774@j.cc.purdue.edu>, ags@j.cc.purdue.edu (Dave Seaman) writes: > > Common blocks will no longer be needed. Why burden implementors with > something that is unnecessary? Why encourage users to stick to outmoded > features of the language? > Augh! Fortran has been around for many many years. Why is there such an insistance upon "improving" a language to the point it is totally different from existing implementations of the language. You will force a rewrite of many millions of lines of working code. This will force the redeployment of many programmers to do this upgrade which will not allow them to work on *new* applications. I have no objection to an evolutionary path for an existing language, but to totally rework the definition as it seems to be proposed is stupid. You also have to consider that there are many thousands of 'amateur' programmers who program in FORTRAN. (e.g. researchers, scientists and the like) who would have to totally relearn the language. Considering the fun we had with learning the new COBOL 74 and are having with COBOL 8x with professional programmers, the thought of retraining all of these people is a scary thought (No flames about the use of the word amateur. This is not meant to be a putdown of these people. I use the word to denote people who write programs as an adjunct to their jobs rather than using all of their time to write code.) In summary, a standard language should NOT BE CHANGED in such a drastic manner. Allow it to evolve, but do not change it into something different.
chris@mimsy.UUCP (Chris Torek) (11/15/87)
In article <422@uni2.bcm.tmc.edu> rick@svedberg.bcm.tmc.edu (Richard H. Miller) writes: >In summary, a standard language should NOT BE CHANGED in such a drastic >manner. Allow it to evolve, but do not change it into something different. There is a simple solution: consider the suffix part of the language name. F66 is a different language from F77, which is different from F8X. If you want to run old F77 programs after the new standard is out, make sure you buy F77 systems, not F8X systems. You would not buy an Ada system to run old COBOL programs.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rwa@auvax.UUCP (Ross Alexander) (11/15/87)
In article <422@uni2.bcm.tmc.edu>, rick@svedberg.bcm.tmc.edu (Richard H. Miller) writes: > Augh! Fortran has been around for many many years. Why is there such an > insistance upon "improving" a language to the point it is totally different > from existing implementations of the language. You will force a rewrite of > many millions of lines of working code. This will force the redeployment of > many programmers to do this upgrade which will not allow them to work on > *new* applications. No it won't. Dusty decks can be complied with the *old* compiler; new decks can be compiled with either, depending on which side of the bed the programmer who wrote them got up on that day. Just because someone invents a new language, x, and chooses to call it y.2 where y is a previously existing language, doesn't make any difference to however many gazillions of lines of y code already out there. I mean really, are the compiler police going to come and take your fortran {II, IV, -66, -77} compiler & libraries away? Get serious. Ross Alexander @ you too can read the path
ags@j.cc.purdue.edu (Dave Seaman) (11/16/87)
In article <50500016@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >Common blocks are the standard way of allocating global memory in Fortran, >and have been since the 1950's. I don't see them as unnecessary. If they >are removed, about 90% of all the Fortran programs I now use will break. You miss the point. F8X still supports common blocks for compatibility with old programs. What I meant was that common blocks are not needed for writing new programs. When I asked "why burden implementors with features that are unnecessary?" I was referring to the proposal that F8X should allow mixing character with noncharacter data in the same common block, which is not allowed in FORTRAN 77. If your existing programs conform to the FORTRAN 77 standard, then they do not mix character with non-character variables in the same common block. Therefore they will still work under Fortran 8X. If you are developing new programs under F8X, there is no need to use common blocks at all. Therefore there is no need for the proposed change. Future versions of FORTRAN may eventually do away with common blocks, but this does not necessarily mean that old programs will have to be scrapped. It should not be difficult to automate the conversion of common blocks into modules. -- Dave Seaman ags@j.cc.purdue.edu
rick@svedberg.bcm.tmc.edu (Richard H. Miller) (11/16/87)
In article <9370@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > > There is a simple solution: consider the suffix part of the language > name. F66 is a different language from F77, which is different from > F8X. If you want to run old F77 programs after the new standard is > out, make sure you buy F77 systems, not F8X systems. There are three rubs here. 1) As I pointed out, the problem is that a large amount of retraining is required to move to this new language. If you are used to programming in a certain style and it completely changes, it becomes hard to switch between the two. 2) If F8X becomes an AFIPS standard, it will become the required compiler to use. (As far as many government contracts are required). 3) There is no guarentee that a vendor will always provide the f77 compiler if he is only required to provide a fortran compiler. I do believe that a good case could be made for developing a language for sicentific use to replace Fortran which does reflect the progress over the last 30 years in language development, just don't call it fortran. Richard H. Miller Email: rick@svedburg.bcm.tmc.edu Head, System Support Voice: (713)799-4511 Baylor College of Medicine US Mail: One Baylor Plaza, 302H Houston, Texas 77030
dd@beta.UUCP (Dan Davison) (11/16/87)
I have been reading the proposed standard and talking for hours with a member of the committee. Since I'm only about .33 way thru the document I'll offer generalizations here and follow up in the future with specifics (that is, chapter and verse details). First, there are a number of typos in the pseudo-BNF which confused me no end, but I suspect that's because of (1) several curious omissions and (2) and my unfamiliarity with reading standards documents. Second, it's a nice language; part APL, part Pascal, part the language we now call fortran. But, it is not fortran. It is also going to be a nightmare for compiler writers and I do not expect to see an 8X compiler in the next two or three years after the standard is approved. Third, the deletion of bit fields can charitably be described as bizarre. Also, the relegation of certain array constructs (FORALL, for those who have the document) to outer slobobia is also, umm, strange. There is an excellent summary booklet "Review and Analysis of Fortran 8x" (Argonne National Laboratory 9700 South Cass Avenue Argonne Illinois 60439) Document ANL-87-40, October 1987. I think it's available to the public. I have gone through mine with a red pen and it is considerably marked up. More to come... -- dan davison/theoretical biology/t-10 ms k710/los alamos national laboratory los alamos, nm 875545/dd@lanl.gov (arpa)/dd@lanl.uucp(new)/..cmcl2!lanl!dd "I refuse to be intimidated by reality any more" "What is reality anyway? Nuthin' but a collective hunch!" --Jane Wagner,via Lily Tomlin
kent@xanth.UUCP (Kent Paul Dolan) (11/16/87)
In article <402@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >In article <422@uni2.bcm.tmc.edu>, rick@svedberg.bcm.tmc.edu (Richard H. Miller) writes: >> Augh! Fortran has been around for many many years. Why is there such an >> insistance upon "improving" a language to the point it is totally different >> from existing implementations of the language. You will force a rewrite of >> many millions of lines of working code. This will force the redeployment of >> many programmers to do this upgrade which will not allow them to work on >> *new* applications. > >No it won't. Dusty decks can be complied with the *old* compiler; new >decks can be compiled with either, depending on which side of the bed the >programmer who wrote them got up on that day. Just because someone invents >a new language, x, and chooses to call it y.2 where y is a previously existing >language, doesn't make any difference to however many gazillions of lines >of y code already out there. I mean really, are the compiler police going >to come and take your fortran {II, IV, -66, -77} compiler & libraries away? >Get serious. > >Ross Alexander @ you too can read the path No the cops won't get the old decks, but the mainframe vendors will upgrade, and when the next 32 bits are added to everyone's busses to allow for more masive memory addressing needs, the compilers will need to be revised to emit code for the new hardware, and suddenly F66 or F77 may not seem like its worth the trouble. Moral: yes, the capability to compile F66 could be expensive to keep. But, the FORTRAN committee has always been highly aware of this problem, using the responsible technique of "deprecating" features while keeping them in operation for another standard review cycle. This warns folks to get rid of them, or at least don't use them any more in _new_ code. We've learned a lot about what is good and bad in maintaining code. Uncontrolled globals, like FORTRAN's COMMON blocks, turn out to be maintenance nightmares. Since FORTRAN shows few signs of folding up its tent and slipping quietly into the night, it is probably a "good thing" to remove these features as we discover their consequences, and to replace them with features that lead to code that is easier to maintain. The problem with the dusty deck is that it doesn't just sit around for free; it costs money to maintain and upgrade, and it costs more money when hard to maintain features are part of the language. So, I guess, if you love FORTRAN, don't suffocate it, let it grow. If it doesn't grow, then it will die, replaced by Modula 2, Ada(tm) or whatever lies just over the horizon in the way of cheaper to maintain langauges. This is spoken from a 26 year love affair with FORTRAN, but with no chance to review the proposed standard (on $700 per month, where do I get $50 for a dpANS?) Kent, the man from xanth.
mcdonald@uxe.cso.uiuc.edu (11/16/87)
/* Written 8:06 pm Nov 15, 1987 by rick@svedberg.bcm.tmc.edu in uxe.cso.uiuc.edu:comp.lang.fortran */ I do believe that a good case could be made for developing a language for sicentific use to replace Fortran which does reflect the progress over the last 30 years in language development, just don't call it fortran. Richard H. Miller Email: rick@svedburg.bcm.tmc.edu /* End of text from uxe.cso.uiuc.edu:comp.lang.fortran */ Such a language already exists. It is called C. If C were not designed for scientific programming, why would it have Bessel functions?
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (11/16/87)
In article <402@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >In article <422@uni2.bcm.tmc.edu>, rick@svedberg.bcm.tmc.edu (Richard H. Miller) writes: >> Augh! Fortran has been around for many many years. Why is there such an >> insistance upon "improving" a language to the point it is totally different >> from existing implementations of the language. You will force a rewrite of >> many millions of lines of working code. This will force the redeployment of >> many programmers to do this upgrade which will not allow them to work on >> *new* applications. > >No it won't. Dusty decks can be complied with the *old* compiler; new >decks can be compiled with either, depending on which side of the bed the >programmer who wrote them got up on that day. Just because someone invents >a new language, x, and chooses to call it y.2 where y is a previously existing >language, doesn't make any difference to however many gazillions of lines >of y code already out there. I mean really, are the compiler police going >to come and take your fortran {II, IV, -66, -77} compiler & libraries away? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Get serious. > >Ross Alexander @ you too can read the path It can happen, not by a compiler police but by economical realities. To support different compilers of the more or less the same language, may be too costly. In that case, it is usually the latest standard that survives and the old one is out. How many installations still use f66 compilers in addition to their f77 compilers (especially since FORTRAN is not the preferred language of the CS people)? Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________
jejones@mcrware.UUCP (James Jones) (11/17/87)
------------------------- > Perhaps someone will explain how my present programs will work without > common, if they now use it? Will you volunteer to conver all my old > programs to F8X or C. If you won't do the job for me, why not? I wouldn't, because COMMON blocks and EQUIVALENCE are major sources of obfuscation in FORTRAN programs. From the point of view of writing intelligible programs, the sooner they go away, the better. (I have yet to read the standard, so I can't say for sure, but I certainly hope that the designers have provided reasonable, disciplined ways to do the things one must currently do with COMMON in FORTRAN.) As a student assistant in a university comp center, I saw the results of the great tradition of engineering instructors who no doubt were quite capable in other ways teaching another generation of engineering students to program as incompetently in FORTRAN as they did. If F8X provides a route out of this vicious cycle, then great. James Jones
jay@splut.UUCP (Jay Maynard) (11/22/87)
In article <402@auvax.UUCP>, rwa@auvax.UUCP (Ross Alexander) writes: > [...] Dusty decks can be complied with the *old* compiler; [...] Not necessarily. What happens when the systems supplier, in an example of how he's being so forward-looking, decides to drop support of the old compiler? > Just because someone invents > a new language, x, and chooses to call it y.2 where y is a previously existing > language, doesn't make any difference to however many gazillions of lines > of y code already out there. It does for portability (after all, FORTRAN is more portable than C ever thought about being); what am I supposed to do with my million lines of code when I need to upgrade my ancient, no-longer-supported computer system, and the only machines available only support the "new and improved" language? > I mean really, are the compiler police going > to come and take your fortran {II, IV, -66, -77} compiler & libraries away? > Get serious. No, not the compiler police, but just maybe the computer manufacturers. -- Jay Maynard, K5ZC (@WB5BBW)...>splut!< | uucp: uunet!nuchat!splut!jay Never ascribe to malice that which can | or: academ!uhnix1!--^ adequately be explained by stupidity. | GEnie: JAYMAYNARD CI$: 71036,1603 The opinions herein are shared by none of my cats, much less anyone else.
chris@mimsy.UUCP (12/01/87)
>In article <402@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >>[...] Dusty decks can be complied with the *old* compiler; [...] In article <253@splut.UUCP>, jay@splut.UUCP (Jay Maynard) writes: >Not necessarily. What happens when the systems supplier, in an example of >how he's being so forward-looking, decides to drop support of the old >compiler? Then you are out of luck: you will have to find support elsewhere, or change. What happens now when the systems supplier drops support of the old machine? If there is a market, someone else usually jumps in. >>Just because someone invents a new language, x, and chooses to call >>it y.2 where y is a previously existing language, doesn't make any >>difference to however many gazillions of lines of y code already out there. >It does for portability Not so: if the code is written in portable Y, then running it under any Y compiler/system (as opposed to a Y.2 system) should continue to work. >(after all, FORTRAN is more portable than C ever thought about being); (Hah! Most useful FORTRAN programs or subroutines require *some* change or adjustment to be brought from one environment to another: all those machine-specific constants in the engineering libraries are a good example. Due to widespread use, many of these programs and libraries are carefully written so as to isolate the machine dependencies.) >what am I supposed to do with my million lines of code when I need >to upgrade my ancient, no-longer-supported computer system, and >the only machines available only support the "new and improved" language? This is like asking `what do I do with my 1937 Ford now that a part on it broke and Ford does not make it anymore?' You find someone else who supports it, do it yourself, or give up on it, whichever is most economical and fits your constraints. If you really believe that losing F77 (or F66) support will be a problem, write some solutions now: then when the problem occurs you will be all set to (as a friend of mine would say) make Big Bucks. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
atbowler@orchid.UUCP (12/02/87)
In article <9581@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >(Hah! Most useful FORTRAN programs or subroutines require *some* >change or adjustment to be brought from one environment to another: >all those machine-specific constants in the engineering libraries >are a good example. Due to widespread use, many of these programs >and libraries are carefully written so as to isolate the machine >dependencies.) This should be emphasized. "portable" does not mean "machine-independant" or "implementation independant" merely that it is less work to change the existing code than it is to start over from scratch. "implementation-independant" code is portable, the converse is not true. A useful concept (although perhaps not an easily measured one) is the idea of a portabilty index for a program 1 - (time to port program)/(time to rewrite completely) machine independant code would have an index of 100%, completely machine specific would be zero. Clearly it is a good idea to try to increase the index for any program you are writing but there will be efficiency, convienience and other practical tradeoffs that mean you usually settle for something less than a 100% index. The technique of explicitly dividing a program into machine independant, and machine dependant parts (either separate proceedures or parameters) can do a lot to increase portability with little cost in efficiency etc.
fpst@hubcap.UUCP (Steve Stevenson) (12/03/87)
in article <9581@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) says: > >>In article <402@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >> ....[portability] > (Hah! Most useful FORTRAN programs or subroutines require *some* > change or adjustment to be brought from one environment to another: > all those machine-specific constants in the engineering libraries > are a good example. There's a lot more to this than programmer introduced things. The changes in arithmetic can be killers. For example code that has no built in anything running on, say a VAX, may not fly on an IBM due to the drastic differences in floating point arithmetic. To be truly portable, then the concept of a standard language would have to be much more extensive than it is. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@clemson.csnet Department of Computer Science, comp.hypercube Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell