Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!uflorida!mephisto!rutgers!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: EQUIVALENCE, COMPUTED GO TO in FORTRAN 88?
Message-ID: <14178@lambda.UUCP>
Date: 16 Dec 89 02:21:39 GMT
References: <7320@ficc.uu.net>
Lines: 77

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 :-).