Anthony Stone writes:
 > I have a question about write statements with `advance="no"'....
 > Version (b) doesn't do what I want in an interactive program with both
 > input from and output to the terminal. I expect the code
 >
 > write ("(a)",advance="no") "prompt: "
 > read ... stuff
 >
 > to send the prompt to the terminal and wait for the user to type the
 > stuff. According to Metcalf & Reid this is one of the uses for
 > non-advancing output. Compiler (b) doesn't produce the prompt until
 > after the stuff has been entered and the program is ready to print
 > something else.
 >
 > Does the standard specify what should happen? Is this a bug in
 > compiler (b)?

In annex C (C.6.1.5) of f95, the standard mentions this as one of the
possible uses of nonadvancing I/O. It explicitly does *NOT* require
it though. AFter giving an example of such use for prompting, the
annex says

  "The standard does not require that an implementation of
  nonadvancing I/O operate in this manner. For example [your case b]
  is also standard conforming. Such an implentation will not,
  however, allow a prompting mechanism of this kind to operate."

I'd personally have preferred that the standard be more hard-nosed
about requiring this. I think of it as one of the major purposes for
non-advancing output. So I'd probably gripe at the vendor. I'm
afraid that you can't justify it as actually non-conforming, however.
I do read that annex as encouraging implementations like you want.
Seems to me that it is pointing out this as a desirable property of an
implementation, even though it says it isn't required. So you might
be able to use that as at least a little leverage, though the
strongest point is going to be that lots of user programs assume
this behavior (I know that to be true), and such users won't be
pleased with an implementation where it doesn't work.

I'm not 100% sure why it isn't required, but I suspect that it may
just be a case of being below the level at which the standard
specifies implementation details. Since the standard doesn't talk
about interactive terminal screens at all, it might be a big deal to
get into it just for this issue. And then, to address it in full
generality, you might have to worry about all kinds of low-level
details about buffering, etc. and distinguishing exactly what
constitutes an interactive terminal and what doesn't. Suppose
you feed standard out through the unix tee utility - a fairly
common thing to want to do, I might add. Does that still count
as interactive output. I'd like the answer to be "yes", but I'm
afraid that most implementations of tee will break this, and that
this gets into things too far removed from the compiler. This para
is all just my speculation.

Hmm. I was thinking that perhaps the f2k draft had added a bit more
explicit recommendation (though still not a requirement) for the
bahavior that you want. But I don't see it in a quick skim. Perhaps
I'm remembering something I would have liked to have it say instead
of something that it actually does say.


--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
                             | -- Mark Twain