Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.lang.fortran Subject: Re: EQUIVALENCE, COMPUTED GO TO in FORTRAN 88? Message-ID: <7329@ficc.uu.net> Date: 18 Dec 89 01:17:15 GMT References: <7320@ficc.uu.net> <14178@lambda.UUCP> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 83 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. . 'U` Also or . "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