Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!wuarchive!texbell!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: <7320@ficc.uu.net>
Date: 15 Dec 89 18:34:19 GMT
References: <7305@ficc.uu.net> <14173@lambda.UUCP>
Reply-To: peter@ficc.uu.net (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 83

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