[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 <pavel@parc.xerox.com>
   Fake-Sender: pavel@parc.xerox.com
   References: <9205262146.AA28980@life.ai.mit.edu>
   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.