Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!cochiti.lanl.gov!jlg From: jlg@cochiti.lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: <23881@lanl.gov> Date: 16 May 91 16:43:33 GMT References: <3246@travis.csd.harris.com> <1991May10.002337.22669@ariel.unm.edu> <13372@exodus.Eng.Sun.COM> Sender: news@lanl.gov Distribution: comp Organization: Los Alamos National Laboratory Lines: 124 In article <13372@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: |> [...] |> The other is "obsolescent", which means there are better ways in Fortran 77 <--- |> of doing the same thing (in other words, they were obsolete long ago). Of |> these, only one (alternate return) was new in Fortran 77; none are new in |> Fortran 90. The others are hot items like the arithmetic IF, the PAUSE |> statement, the H edit descriptor, etc. [...] The nine obsolescent features are: 1) Arithmetic IF Agreed. Should be removed. The IOSTAT returns from the standard IO calls should be specific conditions and not negative-zero-positive. What does one have to do with the other? Why tag a feature as obsolescent and then define an appropriate use for it? 2) Real and Double precision DO control variables. Agreed. There must have been a strong lobby from some vendor to get these into the standard to begin with. 3) Shared DO termination and termination on a statement other than END DO or CONTINUE. Well? Shared termination is useful for short loops which contain initialization of multidimensional arrays. The whole array syntax should do this even more clearly and succinctly. Otherwise, I agree. 4) Branching to an END IF statement from outside its block. I always wondered why END IF could be labeled at all. The same thing goes for END SELECT, END DO, and any other block delimiter that can presently be labeled. 5) Alternate return. Now here's trouble. There are two common ways to implement the alternate return capability: the good way and the bad way. The substitute which the Fortran 90 document recommends is the bad way. Consider the example given in the document: CALL SUBR_NAME (X, Y, Z, *100, *200, *300) They recommend replacing this with: CALL SUBR_NAME (X, Y, Z, RETURN_CODE) SELECT CASE (RETURN_CODE) CASE (1) ... CASE (2) ... CASE (3) ... CASE DEFAULT ... END SELECT The major use of alternate return is as a weak kind of exception handling mechanism. 99.99% of all calls (in most people's code) will _NOT_ raise an exception. But the 'recommended' method here is to test after return each time. The subroutine has already made that test (or it couldn't have set the return code), why should the calling routine repeat that work? Further, I've seen (and written) codes in which nearly every procedure called would have to be followed by this long list of tests - this is called _clutter_. A better way to implement alternate return is to have the called routine substitute the return address in the call chain and then execute a normal return. A better way to do this whole thing is to have a full fledged exception handling capability (implemented internally in the way I've just outlined, but using named exception conditions and block structured syntax to describe the scope of each handler). 6) PAUSE statement. Agreed. It is hard to determine what a PAUSE means in the modern computing environment. From some vendors, the chosen meaning is actually something useful, from others it's not. Most likely it's implemented as an intertactive prompt requiring nothing but a carriage return from the user in response. _Usually_ there is a simpler and more flexible way to do this. 7) ASSIGN statements and assigned GOTO. The recommended substitute is to use INTERNAL procedures. I tend to agree. However, they are the same thing in flow control as pointers are in data structuring - and the committee is just adding pointers. 8) ASSIGN statements with FORMAT labels. It's not clear why they chose to make this a separate issue from point (7). In this case, it is clear that CHARACTER variables (and POINTERs to such) are exact replacements semantically - just a different syntax. I have never needed to do this, but those who do can get by without the ASSIGN just fine. 9) H edit descriptors. I disagree here. The proposed standard claims this edit descriptor can be a source of error. So can all others. The issue here is that people can miscount the number of characters in a string and the H descriptor requires an accurate count. The obverse sode of the coin is that the user often needs to know the number of characters in an output FORMAT when planning the page arrangement. The H edit descriptor (by requiring an accurate count) is a built-in reminder to the programmer - so s/he doesn't have to count again when planning alterations. I suppose this is a minor point, but so is the complaint that the proposal cites as the reason for removing the feature - I don't know anyone who's made this error very often - I know of none in which the compiler didn't promptly catch the error (it _IS_ possible to miss if the character string contains text which could be mistaken for FORMAT descriptors, I've just never seen this happen in a real code). Well, that's the list. I suppose that my basic agreement with 7 out of 9 is fairly reasonable. If my agreement with the features being _added_ to the language were to the same degree, I would feel better about the proposal. As can be seen, it takes considerable effort the eliminate features from a language once they've been introduced. Since I think that a _lot_ of the new features will soon find their way to an obsolescent features list, it would be more economical just to leave them out to begin with. J. Giles