Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!shadooby!samsung!cs.utexas.edu!wuarchive!udel!haven!adm!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: <14173@lambda.UUCP>
Date: 14 Dec 89 23:43:44 GMT
References: <7305@ficc.uu.net>
Lines: 80

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.