Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!psuvax1!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: <14179@lambda.UUCP>
Date: 19 Dec 89 01:55:14 GMT
References: <7329@ficc.uu.net>
Lines: 164

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.