[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A few random I/O proposals
From: Pavel Curtis <Pavel@parc.xerox.com>
Sender: Pavel Curtis <email@example.com>
Date: Wed, 27 May 1992 17:33:50 PDT
There've been a bunch of I/O-related topics discussed recently;
here's my two cents:
++ Flushing output
I think that the right solution here, regardless of whether or not
the Scheme I/O system grows out of its `toy' status, is a
recommendation to implementations that, if (current-input-port) and
(current-output-port) both refer to the same interactive I/O device
(e.g., terminal), then operations getting input from
(current-input-port) should flush all pending output on
(current-output-port), if any.
I strongly dislike this solution. It introduces the notion of ttys as
different from other files and it won't work with emacs on systems
without pseudo-ttys. When emacs runs a sub-process on such a system,
it uses pipes for stdin and stdout. I have been careful in SCM to
flush output so that prompts and error messages appear in the right
order and in a timely fashion.
Flushing output on every character would also greatly slow reading (by
several times) from current-input-port. Flush-output is a fairly
benign system call; It can done extra times without harm and if it
doesn't succeed this is not a serious condition.
It might also be useful to have a output-flushing procedure for use
in other situations, but I that would be less interesting until
such time as Scheme had a more well-flushed-out I/O architecture.
On systems where current-output-port can be a pipe, an output-flushing
procedure is a neccesity for implementing prompts and interactive
I also don't think that we should adopt a POSIX-like interface for
I/O, since I believe that's too low-level and unportable (esp. to
non-POSIX systems... :-). I wouldn't mind collaborating with
others on the development of a standard set of Scheme bindings for
POSIX functionality (we are part-way through doing this for use in
SchemeXerox), but I think that should be a separate effort from
describing the language-level I/O facilities.
You can sign me up for this one.