buffered output and prompting

[SANDRA <LOOSEMORE@UTAH-20.ARPA>]

I'm having trouble coming up with a portable way for a CL application
program to read with a prompt string.  What I would like to do is something
like, but more general than, the y-or-n-p and yes-or-no-p functions:
specify a prompt string and then call read, read-line, or read-char.  For a
usual terminal-style interaction, I'd like to have the prompt message
printed out without a newline so the cursor is left at the end of the same
line, and then read.  Aside from the fact that writing out the prompt string
directly prevents you from using alternative interaction styles (like a
pop-up dialog box or whatever), it's unclear that you could guarantee
the same behavior, or even reasonable behavior, in all CL implementations.

CLtL implies that buffered i/o is perfectly acceptable, so I assume one would
have to do a (finish-output) after printing the prompt message to ensure that
it really does get printed.  However, emptying the internal buffer may mean
that the prompt message shows up with a newline on the end, particularly if
the output stream is organized into records with an implicit newline at
the end of each record.  (This is also acceptable, according to page 22.)
Furthermore, the terminal driver provided by the operating system may
include some fancy input editing capabilities that are confused by printing
out random prompt strings; to get the prompt to interact properly with the
editor, you have to pass it to the read function provided by the operating
system.  (In fact, all three of these conditions are true under VMS.)

PSL has a variable that holds the current prompt string, and it's used
whenever you read from the terminal.  Different PSL implementations use
whatever hooks the OS provides to get the right effect.  I also seem to
remember that the NMODE editor does special things with the prompt string
that are more appropriate for its style of interaction.  The point is, the
same code will produce reasonable behavior in all situations.  How can I
get similar portability in CL code?  Do we need to define additional
functions (or additional arguments to existing functions) to support user
interaction?

-Sandra
-------