jh34607@suntc.UUCP (john howell) (12/08/89)
What is the status of 1) EQUIVALENCE 2) COMPUTED GO TO constructions in future fortrans? I recall hearing that these may be on the "not recommended use" list. Thanks. ======================================================================== John Howell uucp: uunet!suntc!jrh Deere & Company MCImail: 360-4047 Technical Center CompuServe: [76666,2505] 3300 River Drive FAX: (309)765-3807 Moline, IL 61265 Voice: (309)765-3784 ========================================================================
brainerd@unmvax.unm.edu (Walt Brainerd) (12/08/89)
In article <143@suntc.UUCP>, jh34607@suntc.UUCP (john howell) writes: > What is the status of > > 1) EQUIVALENCE > 2) COMPUTED GO TO > > constructions in future fortrans? > Computed GO TO is on a list of a few noncontroversial things with the property that they could be considered for removal from the next standard (2001?) after the one coming up. That does not necessarily mean it will be removed from any compilers, however. EQUIVALENCE and COMMON were on this list at one time, but no more. The other stuff on the list is: Arithmetic IF Real and doubple precision DO variables Do loops other than DO-CONTINUE (and of course, the new DO-END DO) Alternate return Branching to and END IF from outside the IF block PAUSE statement ASSIGN and assigned GO TO statements Assigned format specifiers There were better ways to do all these things already in Fortran 77. -- 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) (12/09/89)
In article <580@unmvax.unm.edu>, brainerd@unmvax.unm.edu (Walt Brainerd) writes: > In article <143@suntc.UUCP>, jh34607@suntc.UUCP (john howell) writes: > > What is the status of > > > > 1) EQUIVALENCE > > 2) COMPUTED GO TO > > > > constructions in future fortrans? > > > Computed GO TO is on a list of a few noncontroversial things > with the property that they could be considered for removal > from the next standard (2001?) after the one coming up. You would think after being on X3J3 all these years, this guy would know what is in the proposed 8x (but it is a brain damaging process). The computed GO TO is not in any way indicated in 8x as possibly being removed, only the assigned GO TO. Some wrote in response to my posting that I should show what the replacements are. These can all be done syntactically; in fact I hope to have in my hands a little program that does them sometime soon. This info appears in Appendix B of the proposed 8x. 1. Arithmetic IF obviously can be replaced with logical or block IF. 2. All DO loops obviously can be rewritten, each with its own CONTINUE. 3. An alternate return can be done by passing in an additional argument, say, RETCOD, and then branching to wherever you want based on the its value using a block IF. (The 8x CASE will do it better.) 4. Who knows what PAUSE might do, but in most cases, it can be replaced by a PRINT to the standard output and a READ to cause continuation. 5. An ASSIGN and assigned GO TO can be replaced by assigning the value to an integer and then branching with a block IF based on the value. 6. Assigning a format statement label can be replaced by assigning the format specification to a character string and using the character string as the format. 7. DO loops with real and dp DO variables can be rewritten using an integer DO variables and an assignment to the replaced DO variable. Please do not assume I am claiming that all of the replacements are more efficient, or in all cases, more convenient to use. I think in almost all cases, the code will be more maintainable. (I personally don't see that using a real DO variable is any worse than putting real values in an IF statement; both may be bad practice, but only one is on the list. This could be argued for hours, of course.) (The computed GO TO could be replaced by block IFs, but not as gracefully and efficiently, but will be replaceable by the 8x CASE statement.) In the next standard after 8x, the computed GO TO may be on the "hit" list for removal from the next standard after that (Fortran 2011?), so it can be eliminated from compilers in 2033 if nobody needs it any longer. (Getting rid of it in 2022 is considered too soon by many, even though Fortran will be twice as old then as it is now!) -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (12/09/89)
In article <581@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >7. DO loops with real and dp DO variables can be rewritten using an > integer DO variables and an assignment to the replaced DO variable. This is not true. You could not be guaranteed of getting the exact same effect. The only way to do this is with if statements on the previous loop variable itself and goto's, along with explicit adding of the increment. But admittedly it is very easy. > > >(The computed GO TO could be replaced by block IFs, but not >as gracefully and efficiently, but will be replaceable by the 8x >CASE statement.) > Certainly these will work, but they are not as clean in certain cases. In some cases they will provide a "better" replacememt, in other cases not so good. Doug McDonald
peter@ficc.uu.net (Peter da Silva) (12/11/89)
In article <581@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: > 4. Who knows what PAUSE might do, but in most cases, it can be replaced > by a PRINT to the standard output and a READ to cause continuation. Heaven forbid I should defend one of the weirder aspects of FORTRAN, but this is now actually a useful feature. In a hosted implementation on a windowing system, PAUSE could reasonably be expected to put up a requestor or dialog box and wait for a mouse click... something that a simple PRINT+READ can't do. Now for the $64000 question: do any Fortrans do this? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "If you want PL/I, you know where to find it." -- Dennis
jlg@lambda.UUCP (Jim Giles) (12/12/89)
From article <581@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > [...] > 1. Arithmetic IF obviously can be replaced with logical or block IF. And ... Logical or block IFs can obviously be replaced by arithmetic IFs as well. The battle over which is better _in_general_ has already been waged elsewhere. My question is: if you don't want people to use the arithmetic if, WHY define the IOSTAT parameter in such a way that a three way branch is the most natural? > [...] > 5. An ASSIGN and assigned GO TO can be replaced by assigning the value > to an integer and then branching with a block IF based on the value. Suppose I have a code sequence: C With assigned GOTO C Without assigned GOTO 999 continue 999 continue ... ... [code to do some useful thing] [code for same useful thing] ... ... goto iret if (iret.eq.1) then [goto the first return] ... endif This faces two problems. First, the assigned GOTO is MUCH more readible and easy to maintain. Second, if you add another 'call' to the 999 label the assigned GOTO version doesn't need to be modified - the other does. The feature that REALLY replaces the assigned GOTO is internal procedures. Except internal procedures can't be nested and assigned GOTO can allow nested usage. > [...] > (The computed GO TO could be replaced by block IFs, but not > as gracefully and efficiently, but will be replaceable by the 8x > CASE statement.) MOST uses of the computed GOTO can be done as CASE statements. Indeed, most of my usage of computed GOTO directly emulates CASE statement semantics. However, neither block IFs nor CASE statements allow a satisfactory replacement for the following: GOTO (101,102,103), iselect STOP 'ISELECT is out of range' 101 continue [Print the day of week] 102 continue [Print the date] 103 continue [Print the time] Here the code has been written to "gradually" change its behaviour based on the ISELECT variable. It either prints just the time, or the date and the time, or the day-of-week plus date and time. Solutions to do this without the computed GOTO always are harder to read and maintain than this is. I come across this "gradual" code shift problem only once in a while, but when I do there's nothing better than the existing computed GOTO.
jlg@lambda.UUCP (Jim Giles) (12/12/89)
From article <1989Dec9.153357.25886@ux1.cso.uiuc.edu>, by mcdonald@aries.scs.uiuc.edu (Doug McDonald): > In article <581@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: > >>7. DO loops with real and dp DO variables can be rewritten using an >> integer DO variables and an assignment to the replaced DO variable. > This is not true. You could not be guaranteed of getting the exact > same effect. The only way to do this is with if statements on > the previous loop variable itself and goto's, along with explicit > adding of the increment. But admittedly it is > very easy. What you have just described is _NOT_ the semantics of the existing DO loop facility. There is no test on the loop variable in each trip through the loop nor is there any adding of the increment. The trip count for the loop is computed before the loop begins and the loop mechanism usually decrements this (integer) trip count until it reaches zero. (See ANSI X3.9-1978, Section 11.10.3 on page 11-7.) Now, if you use the iteration variable within the loop, it _may_ be computed by explicit incrementation. On the other hand, it may be implemented as a linear function of the remaining trip count. The choice is at the discretion of the compiler writer - not you. By the way, the trip count is calculated as: TC=MAX(INT(M2-M1+M3)/M3),0) where M1, M2, and M3 are the loop parameters. That is: DO 10 var = M1, M2, M3 So, obviously, you could avoid using REAL or DOUBLE loop parameters by computing the above trip count yourself and using it in the DO statement: DO 10 itemp = 1, TC var=M1+(itemp-1)*M3 Now you really _DO_ have an exact replacement of the original DO. That is, unless you implementor chose the iterative incrementation method for handling the iteration variable - the world ain't perfect.
jlg@lambda.UUCP (Jim Giles) (12/12/89)
From article <7255@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > [...] > Heaven forbid I should defend one of the weirder aspects of FORTRAN, but this > is now actually a useful feature. In a hosted implementation on a windowing > system, PAUSE could reasonably be expected to put up a requestor or dialog > box and wait for a mouse click... something that a simple PRINT+READ can't do. But in this case you would simply replace the PAUSE with a CALL REQ_BOX("message") instead of a PRINT+READ. The point is that PAUSE has no semantics which cannot be handled more flexibly and more explicitly by other means already in the language. PAUSE only serves a useful purpose on strict batch systems with no interactive I/O (not even to the operator's console). It's been a long time since most of us have even seen one of those!
khb@chiba.Sun.COM (chiba) (12/13/89)
In article <143@suntc.UUCP> jh34607@suntc.UUCP (john howell) writes: >What is the status of > > 1) EQUIVALENCE > 2) COMPUTED GO TO > >constructions in future fortrans? The current (and all previous that I know of) draft of Fortran 8x (or other title :>) include these features. > >I recall hearing that these may be on the "not recommended use" list. Some of what EQUIVALENCE is used to accomplish can be done better with newer constructs. Computed goto can be replaced by the CASE construct. X3J3 did have a list of features which are standard conforming, but which may be deleted in about 20 years or so (the depreciated features). That list was removed because many found it objectionable. ANSI rules only specify that a 1 rev (aprox 10 years for fortran ... longer this time) warning be given ... so the list was not strictly speaking necessary. In Metcalf and Reid's Fortran 8x Explained they have good descriptions of what features are redundant and why. Just as I "purified" old '66 decks (changed holleriths to character, etc.) over a period of years, I intend to slowly fix all the codes I touch to use the newer features where they are better. In 10-30 years some of the oldest redundant features will almost certainly start to disappear ... software may last forever ... but it can be upgraded in a sensible fashion. 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"
peter@ficc.uu.net (Peter da Silva) (12/14/89)
In article <14169@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: > But in this case you would simply replace the PAUSE with a > CALL REQ_BOX("message") instead of a PRINT+READ. Heaven forbid I should defend a feature of Fortran against Jim Giles, but the appropriate behaviour of PAUSE is implementation specific. It is not just PRINT+READ or CALL REQBOX. Under BSD, the most useful implementation of PAUSE is to print a message and send oneself a SIGSTOP, for example. Or what about a UNISYS 1100 (we have a bunch of those downstairs) where it could put out a request on the operator's console (it doesn't, but it should. This is a quality-of-implementation issue). In regular UNIX, it might even make sense to fork an interactive shell. The point is not that you can't do any such thing without PAUSE, but that while the behaviour that PAUSE implements is implementation-specific, the semantics have a close correspondance across a wide variety of systems. > The point is > that PAUSE has no semantics which cannot be handled more flexibly > and more explicitly by other means already in the language. OK, what's the other means? CALL PAUSE(message)? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
jlg@lambda.UUCP (Jim Giles) (12/15/89)
From article <7305@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > In article <14169@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: >> But in this case you would simply replace the PAUSE with a >> CALL REQ_BOX("message") instead of a PRINT+READ. > > Heaven forbid I should defend a feature of Fortran against Jim Giles, but > the appropriate behaviour of PAUSE is implementation specific. It is not > just PRINT+READ or CALL REQBOX. [...] This was exactly my point. By avoiding thge PAUSE statement, the user can get the functionality he wants rather that what the implementor chose to give him. [...] Under BSD, the most useful implementation > of PAUSE is to print a message and send oneself a SIGSTOP, for example. On my SUN workstation, if I want to write a message and send SIGSTOP, that's what I do! I have no idea whether the SUN Fortran compiler implements PAUSE that way - but I can still use it. On the other hand, I can also do WRITE/READ or tell the X11 toolkit to put up a message box, or I can fork a C-shell and wait for it to die, etc.. I can't alter the semantics of PAUSE that way at will. (Or, instead if X11, I might need a Sunwindows interface or an open look interface, etc.. This is why the PAUSE statement can't put up a responder box - the compiler doesn't know which window environment you use!) > [...] > Or what about a UNISYS 1100 (we have a bunch of those downstairs) where it > could put out a request on the operator's console (it doesn't, but it should. > This is a quality-of-implementation issue). In regular UNIX, it might > even make sense to fork an interactive shell. > > The point is not that you can't do any such thing without PAUSE,[...] Why not? I can do all the things I just mentioned without PAUSE. It is true that some of these things require some bridge routines (none of X11 is directly Fortran callable for example). But this, as you say, is a quality-of-implementation issue. The point is, I can do all of this stuff. If I write a library of bridges, other people can use my library and do this stuff witout working through the coding themselves. I don't use any UNISYS machines, but I'll bet that the assembler (at least) permits the user to write code that sends messages to the operator. I know that UNIX system V lets me fork shells from Fortran (indirectly through the system interface library bridges). > [...] but that > while the behaviour that PAUSE implements is implementation-specific, the > semantics have a close correspondance across a wide variety of systems. And that semantics is usually WRITE/READ. > [...] >> The point is >> that PAUSE has no semantics which cannot be handled more flexibly >> and more explicitly by other means already in the language. > > OK, what's the other means? CALL PAUSE(message)? How about WRITE/READ, or CALL REQ_BOX(message), or CALL WRITE_TO_OPERATOR_WAIT_REPLY(message), or CALL FORK_SHELL_AND_WAIT_ITS_DEATH(message), or etc.. All these will be legal in Fortran 8x which allows 31 character names. This allows the user the flexibiltiy of several different semantics while being explicit about the meaning of each. Even CALL PAUSE(message) is a better solution than the PAUSE statement. At least here, if I don't like what the implementor chose I can write my own PAUSE subroutine and put it higher in the library search path than the built-in PAUSE subroutine. There is no way to change the functionality of the PAUSE statement even I you wanted to (often, actually most implementations turn the PAUSE statement into a library call anyway - but the library routine name is often not PAUSE so you'd have to know the system library internals in order to replace the PAUSE statement with something you like). Having said all this, it doesn't matter to me whether the committee retains PAUSE or not since I don't use it. The reason I am posting this is to counter the false claim by Peter da Silva that PAUSE does things which can't be done any other way. I have yet to find any such limitation.
peter@ficc.uu.net (Peter da Silva) (12/16/89)
In article <14173@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: > This was exactly my point. By avoiding thge PAUSE statement, the user can > get the functionality he wants rather that what the implementor chose to > give him. Pardon my C, but I'm not familiar with how Fortran deals with the conditional compilation problem: Would you prefer: #ifdef BSD puts(message); signal(getpid(), SIGSTOP) #else # ifdef UNIX puts(message); system("exec $SHELL -i"); # else # ifdef MACINTOSH dialog_box(message); # else # ifdef AMIGA displayrequest(message); # else # ifdef EXEC1100 oprequest(message); # else puts(message); gets(junk); # endif # endif # endif # endif #endif Or would you prefer PAUSE message PAUSE provides a portable way to request operator action, to be implemented as efficiently as possible on the system it's running on. It has (unlike many features of FORTRAN) an actual, positive value. Or aren't you concerned about portability? > > The point is not that you can't do any such thing without PAUSE,[...] > Why not? I can do all the things I just mentioned without PAUSE. OK, how do you get a response from the operator console on a UNISYS 1100? You can do them, but you won't. Because you don't know how. Because it's too much trouble. And if you have the thing exec a shell on UNIX it's sure not gonna make sense on a MAC. > And that semantics is usually WRITE/READ. > But not always. On at least one BSD system it does send a SIGSTOP. > How about WRITE/READ, or CALL REQ_BOX(message), > or CALL WRITE_TO_OPERATOR_WAIT_REPLY(message), or > CALL FORK_SHELL_AND_WAIT_ITS_DEATH(message), or etc.. OR OR OR OR OR. And any given program is gonna have *all* of these? > Even CALL PAUSE(message) is a better solution than the PAUSE statement. Fine. Put it in the standard. But don't take useful functionality out without providing an alternative. > this is to counter the false claim by Peter da Silva that PAUSE does > things which can't be done any other way. Not portably. I guess it's only us C-language weenies who care about portability. What? The Software Tools VOS was written in Fortran? I'm sure Jim Giles doesn't use it. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
jlg@lambda.UUCP (Jim Giles) (12/16/89)
From article <7320@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > In article <14173@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: >> This was exactly my point. By avoiding thge PAUSE statement, the user can >> get the functionality he wants rather that what the implementor chose to >> give him. > [... Long set of IFDEFs showing various PAUSE-like effects on > various systems ...] > Or would you prefer > > PAUSE message > [...] > Or aren't you concerned about portability? Aparently I am more concerned about it than you are - if the examples you gave are truly representative of the various ways PAUSE is implemented on systems you have access to. The only thing you have done is demonstrate that PAUSE _ISN'T_ a portable feature. >> > The point is not that you can't do any such thing without PAUSE,[...] > >> Why not? I can do all the things I just mentioned without PAUSE. > > OK, how do you get a response from the operator console on a UNISYS 1100? If the guy who wrote the Fortran compiler on the UNISYS machine could make PAUSE get a response from the operator's console then it must be possible to write a library routine to do the same thing. Such a library routine would be a much better thing than pause because it would have the explicit function of communicating with the operator. By using PAUSE to communicate to the operator you have made your code non-portable. Most other systems don't implement PAUSE as an operator message. Suppose a code relies upon the PAUSE statement to tell the operator top mount tapes or start a server or something. Will the code continue to work when you move it to (say) a Cray? NO! In the Cray environment PAUSE is implemented as WRITE/READ. If you want to send a messaage to the operator, you've go to make a system call. On the other hand, if I write a subroutine called OPERATOR and use it instead of PAUSE, I can provide the required functionality (it it's availabe at all) on all the systems I move to. In fact, I have a built-in diagnostic now - if the routine OPERATOR shows up as an unsatisfied external I know _specifically_ one of the things I need to do to port the code. > [...] And if you have the thing exec a shell on UNIX it's > sure not gonna make sense on a MAC. In which case you code _CAN"T_ be ported to a MAC!! If your code relies upon the ability to fork a shell and the machine you're on can't do that, then you're just flat out of luck. Having the implementor replace one functionality with another in (from the user's point of view) an arbitrary way does _NOT_ solve the problem. But it may hide the problem if the original coder is not the one trying to port the code, you may THINK that PAUSE still does what you need - even though it doesn't. > [...] >> this is to counter the false claim by Peter da Silva that PAUSE does >> things which can't be done any other way. > > Not portably. I guess it's only us C-language weenies who care about > portability. [...] I think I have amply demonstrated that the PAUSE statement is _NOT_ portable. Neither is it under the explicit control of the user. That's two strikes against it. The only point in its favor is that it's succinct and is available in all Fortran environments (though it doesn't always do what you expect). As for C's vaunted portability: if PAUSE is the only way to do it, and since C doesn't have PAUSE, how do _you_ get a response from the operator console on a UNISYS 1100 in C? Well, I'll tell you: C uses the methodology that I'm recommending here! C does this kind of thing through library functions which have clearly defined functionality. Hmmm.... Really strange to be defending the C methodology against Peter da Silva: a died in the wool Fortran hater/C lover. I sure hope nobody's watching :-).
peter@ficc.uu.net (Peter da Silva) (12/18/89)
In article <14178@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: > Aparently I am more concerned about it than you are - if the examples > you gave are truly representative of the various ways PAUSE is > implemented on systems you have access to. The only thing you have > done is demonstrate that PAUSE _ISN'T_ a portable feature. PAUSE is portable. It presents the operator with a message in an appropriate format and waits for a response. The implementation isn't portable, but that's to be expected. I could write a similar set of #ifdefs for, oh, "OPEN". Let's see, the same OPEN statement can: Allocate and rewind a tape. Allocate a card reader and read the first card. Search a disk for a file name. Search an in-memory list for a file name. Search a series of disks for a volume name. Search an in-memory list for a device name, then go back to square one. Allocate a serial port and raise DTR. Create an on-disk archive file and copy a tape to it. By your standards, this means OPEN isn't portable. I say that this is an implementation issue that shouldn't be the concern of the programmer. Especially since Fortran programmers tend to be scientists and engineers trying to get real work done rather than computer nerds like me (and presumably like you). > If the guy who wrote the Fortran compiler on the UNISYS machine could > make PAUSE get a response from the operator's console then it must be > possible to write a library routine to do the same thing. Such a library > routine would be a much better thing than pause because it would have > the explicit function of communicating with the operator. THAT'S THE EXPLICIT FUNCTION OF PAUSE! Communicating the existence of an exception to someone who can make a decision and act on it. If the only such person is the operator... QED. > Suppose a code relies upon the PAUSE statement to tell the > operator top mount tapes or start a server or something. Then the person running the code should pick up a human interface device and give the operator a phone call, or walk down the corridoor to the room. And so on and so forth. > In which case you code _CAN"T_ be ported to a MAC!! If your code relies > upon the ability to fork a shell and the machine you're on can't do that, > then you're just flat out of luck. It doesn't. It assume the ability to inform a human of a condition and wait for a response... on a UNIX system the best way to do that may be to fork a shell (if stdin is a terminal), and so on... > I think I have amply demonstrated that the PAUSE statement is _NOT_ > portable. No, what you have demonstrated is that you don't understand what people use the PAUSE statement for. Not only do you not understand C, you don't even understand Fortran. > As for C's vaunted portability: if PAUSE is the only way to do it, > and since C doesn't have PAUSE, how do _you_ get a response from > the operator console on a UNISYS 1100 in C? The standard C library is well known to be missing many valuable tools. So what? That's not relevent to this argument. > Really strange to be defending the C > methodology against Peter da Silva: a died in the wool Fortran > hater/C lover. Sigh. If you had a better understanding of C usage and methods (not methodology: that's the *study* of methods) you'd get into fewer flame wars on comp.lang.c. Maybe you should pay some attention to the times I've disagreed with comp.lang.c.gods. C isn't the perfect language. It's just the only halfway decent one available on more than a small fraction of systems out there. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
brainerd@unmvax.unm.edu (Walt Brainerd) (12/18/89)
In article <7329@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <14178@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: > > Aparently I am more concerned about it than you are - if the examples > > you gave are truly representative of the various ways PAUSE is > > implemented on systems you have access to. The only thing you have > > done is demonstrate that PAUSE _ISN'T_ a portable feature. > > PAUSE is portable. It presents the operator with a message in an appropriate > format and waits for a response. The implementation isn't portable, but that's > to be expected. I could write a similar set of #ifdefs for, oh, "OPEN". > There are many things that are standard Fortran that are not portable. PAUSE is one of them. What I mean by this is that there is nothing in the description of the language (the standard) that even hints at how it should be implemented (the semantics), except that execution is suspended and the rest of the stuff in the statement (char string or digits) must be "accessible". Apparently this means it could be flashed on a lighted display on Times Square for a nanosecond, for example. Therefore a programmer trying to write software to port to many systems cannot rely on any particular behavior. A different issue is how many of the many systems out there take somewhat the same kind of action. Even if they did, this would be some kind of "de facto" uniform conformance, not one guaranteed by the language specification, hence not something one can rely on when trying to writing portable software. > No, what you have demonstrated is that you don't understand what people use > the PAUSE statement for. Not only do you not understand C, you don't even > understand Fortran. > This is patently false, as anyone who has read this column knows (that does not mean, of couse, that I agree with him a lot!) -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800
peter@ficc.uu.net (Peter da Silva) (12/18/89)
> What I mean by this is that there is nothing in > the description of the language (the standard) that even hints at how > it should be implemented (the semantics), Which is quite correct, because different hardware and operating systems have different requirements. What's appropriate for a Macintosh isn't appropriate for a batch environment. And neither of these would have the same pause semantics as an interactive task under UNIX. MOST of the time TYPE and READ is just fine. But it's not appropriate for a batch or graphical environment. And a batch environment is where Fortran was born... which is why it has this feature (and why C, born in an interactive text environment, doesn't). > Apparently this means it could be flashed on a lighted > display on Times Square for a nanosecond, for example. This is a quality of implementation question. One could similarly claim that an OPEN statement could place a long-distance operator-assisted call to New York and have a newspaper vendor in Grand Central Station key the data in via touch-tone. Both claims are ludicrous. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
jlg@lambda.UUCP (Jim Giles) (12/19/89)
From article <7329@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > [...] > PAUSE is portable. It presents the operator with a message in an appropriate > format and waits for a response. The implementation isn't portable, but that's > to be expected. From ANSI Xs.9-1978 Fortran 77, section 11.13: ... Execution of a PAUSE statement causes a cessation of execution of the executable program. Execution must be resumable. At the time of cessation of execution, the digit string or character constant is accessable. Resumption of execution is not under control of the program. If execution is resumed, the execution sequence continues as though a CONTINUE statement were executed. I don't see anything here about "presents the operator with a message" whether it has an "appropriate format" or not. It's not just that the implementation isn't portable - the semantics are not! Most implementations provide _more_ functionality than the minimum required above. It is possible (and quite usual) for users to become reliant on this additional functionality. With respect to the PAUSE statement it is difficult to use it at all without relying in some way on the local version. > [...] > Especially since Fortran programmers tend to be scientists and engineers > trying to get real work done rather than computer nerds like me (and presumably > like you). Then, why is it that these people "trying to get real work done" typically avoid using PAUSE? Why is it that those who _DO_ use PAUSE are fully aware of its local implementation quirks - and actually rely upon them? It couldn't be that people "trying to get real work done" aren't interested in the theoretical purpose of the PAUSE statement as expounded by self- proclaimed experts? It couldn't be that they use (or don't use) PAUSE as they find it - warts and all? NAW - that would be too pragmatic an approach! >> If the guy who wrote the Fortran compiler on the UNISYS machine could >> make PAUSE get a response from the operator's console then it must be >> possible to write a library routine to do the same thing. >> [...] Such a library >> routine would be a much better thing than pause because it would have >> the explicit function of communicating with the operator. > > THAT'S THE EXPLICIT FUNCTION OF PAUSE! Gee, thanks for telling me. I couldn't find any part of the standard which gave an explicit function for PAUSE. In fact, it is often not used that way. Users tend to use the features that the implementor provides - users usually do _NOT_ restrict themselves to the _supposed_ intensions of the standard committee. > [...] >> Suppose a code relies upon the PAUSE statement to tell the >> operator top mount tapes or start a server or something. > > Then the person running the code should pick up a human interface device and > give the operator a phone call, or walk down the corridoor to the room. And > so on and so forth. This assumes that the user knows the operator's phone number and/or works within walking distance of the machine. Some of _our_ users are not even aware that the machine they are using is in New Mexico! Furthermore, it requires the user to stick around while his production job runs so that he'll be on hand when it needs a tape mount or something. Many of our users have simulations which require _DAYS_ of Cray CPU time to execute. Naturally they would not be happy with a program feature which required them to be present the whole time in order to just relay messages to the operator. No, if your program relies upon being able to send messages to the operator then it better do so _explicitly_ and not rely on the whims of the PAUSE implementation. > [...] >> In which case you code _CAN"T_ be ported to a MAC!! If your code relies >> upon the ability to fork a shell and the machine you're on can't do that, >> then you're just flat out of luck. > > It doesn't. It assume the ability to inform a human of a condition and wait > for a response... on a UNIX system the best way to do that may be to fork a > shell (if stdin is a terminal), and so on... Again you are assuming that the user only uses PAUSE to perform some minimal functionality. I assure you that if PAUSE forks a shell on some system then there are programs which _rely_ on that fact. For example, suppose the PAUSE looks like this: PAUSE "Re-edit file BLIVET.DOC into new form -- I'll wait" The user did this because he "knows" that PAUSE forks a shell and that he can invoke any favorite text editor from within such a shell. If the MAC implementation of PAUSE doesn't allow the user to run a text editor on the file while the PAUSEd program waits, it isn't an adequate replacement! >> I think I have amply demonstrated that the PAUSE statement is _NOT_ >> portable. > > No, what you have demonstrated is that you don't understand what people use > the PAUSE statement for. Not only do you not understand C, you don't even > understand Fortran. I began programming in 1967. I worked my way through college as a consultant at the university computing center - that is, my job was to help users with minor questions and problems with their programs. Since that time I have often been employed in a similar role - helping other users to make efficient use of the various programming environments I've seen. My present job puts me within 10 steps of the consulting office here. I myself consult with users on the use of the software that I maintain (which is, at present, the Cray loader-linker: LDR). I am as familiar as anyone (and probably more than most) with the ways that programming language features are used. As for PAUSE, most users - that use it at all - use it for what it _DOES_, not for what some computing science guru says it's for. And users are much more clever than you give them credit for - if there's a way to "misuse" an implementation of a given feature they'll find it. Further, most users believe that the implementation they are using is representative of all others - they would be very shocked to find that other implementations are different in any way (the vast majority of users have never even _SEEN_ a standards document). I assure you that if you change the semantics of a feature even a little bit, you will break a large percentage of the programs that use that feature. Furthermore, if you change the semantics of a feature by a LOT (say, by replacing an operator message with a fork to a shell), you will break nearly _EVERY_ code that uses the feature! It is for these reasons that I am particularly sensitive to "implementation defeined" features in a programming language. I see vaguely defined features as nothing more or less than a major portability problem. In some cases the usefulness of the feature outweighs its ambiguity. But in other cases (PAUSE included), the feature is too vague to be genrerally useful. In the old days, when PAUSE _really_was_ always implemented as a message to the operator, it was a useful construct - not anymore. >> As for C's vaunted portability: if PAUSE is the only way to do it, >> and since C doesn't have PAUSE, how do _you_ get a response from >> the operator console on a UNISYS 1100 in C? > > The standard C library is well known to be missing many valuable tools. > > So what? That's not relevent to this argument. You've missed the entire point of my remark! I don't have any idea whether the C library on a UNISYS 1100 has a way of sending messages to the operator. I was pointing out that if it _DOES_ it will be in the form of a callable function - NOT a PAUSE statement! Further, I was pointing out that if the feature were to be placed in the C standard library - it wouldn't be some "implementation defined" hogwash (I hope), but would be called 'tell_operator', or somesuch, and have a clearly defined functionality. I was pointing out that this was one of the few places where the C approach to things was better than Fortran. Perhaps I'm wrong. Perhaps you _prefer_ vagueness in your programming environment definition (it would explain part of your liking for C). I don't. I dislike vagueness. I _try_ to avoid relying on features which are vaguely defined. All programming languages some features which are unavoidably dependent upon the implementation (word size, floating point precision and range, byte vs. word addressability, etc.). I'd like to see languages designed with as few of these as possible.
peter@ficc.uu.net (Peter da Silva) (12/19/89)
In article <14179@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: [lots of flames] > I don't. I dislike vagueness. I _try_ to avoid relying on features > which are vaguely defined. That about covers every input/output statement in every language. how can you live with yourself? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
king@native.usc.edu (Greg King) (12/21/89)
In article <7335@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >This is a quality of implementation question. One could similarly claim that >an OPEN statement could place a long-distance operator-assisted call to New >York and have a newspaper vendor in Grand Central Station key the data in >via touch-tone. You mean....this is not a good way to implement OPEN?