Re: Issue PEEK-CHAR-READ-CHAR-ECHO

["Steve Bacher (Batchman)" <SEB1525@draper.com>]

> From: "Kim A. Barrett" <IIM%ECLA@eclc.usc.EDU>
> Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
> To: kmp@scrc-stony-brook.ARPA
> Cc: cl-cleanup@sail.stanford.EDU, iim%ECLA@eclc.usc.EDU
 
> 1. Define two operations on streams, ECHO and UNECHO.
> 2. echo-streams, when reading a character, apply echo to the output stream and
>    the character.  unread on echo-streams calls unecho on the output stream 
>    and char, in addition to passing along the unread to the input stream.
> 3. Other meta-streams simply pass these operations along to their output side.
> 4. data-streams have two choices, depending on whether they have the
>    capability to 'back out' output.  If they can back it out, then echo is
>    equivilent to write-char, and unecho backs it out.  If they can't, then
>    they record the echo in a slot, writing any already pending echo.  unecho
>    clears the pending echo slot.  all normal output operations first write
>    pending echo.  a normal close also forces pending echoing.

> There is potentially more hair involved, intended to either support or
> complain about improper usage, like calling unread after peek, doing output
> between the read and the unread, &etc.  Note that this depends on the single
> unread restriction in order to work right in all cases.

There SURE IS more hair involved.  All you're doing is punting the basic
problem down to a lower level.  Maybe the stream internally takes the actual
send-the-character-to-the-output-stream and implements it via SEND-OUT and
UN-SEND-OUT calls, where SEND-OUT buffers the character in case an UN-SEND-OUT
comes along...
 
In the
 
'foo(* a b)
 
example, when the ( is seen, either it gets echoed at that point or it
doesn't.  This ECHO/UNECHO stuff doesn't change anything.  And posing a
restriction on stream output between READ and UNREAD is unreasonable,
in my opinion.