[R6RS] Changing the transcoding mid-stream

[dyb at cs.indiana.edu]

> > Should we consider:
> >   (call-with-ports proc port ...)
> > or
> >   (call-with-ports list-of-ports proc)
> > instead of or in addition to call-with-port?
>
> Those can be written as macros.  If people find them
> useful, they can write a SRFI for them.

I was actually thinking of a procedure, probably replacing the one-port
version.  It seems to me that:

   (call-with-ports (list <open operation>)
     (lambda (---)
       ---))

or

   (call-with-ports
     (lambda (---) ---)
     <open-operation>)

isn't a lot more onerous than:

   (call-with-port <open operation>
     (lambda (---)
       ---))

and generalizes nicely in the fairly common case where one wants to
pass different input and output ports (or two different input ports,
e.g., for copying a file).

Another possibility is

  (call-with-ports port ... proc)

which eliminates the need to make a list while putting the port open
operations first.  So I can write:

  (define copy-file
    (lambda (path1 path2)
      (call-with-ports (open-file-input-port path1)
                       (open-file-input-port path2)
        (lambda (p1 p2)
          ---))))

instead of

  (define copy-file
    (lambda (path1 path2)
      (call-with-port (open-file-input-port path1)
        (lambda (p1 p2)
          (call-with-port (open-file-input-port path2)
            (lambda (p1 p2)
              ---))))))

I suspect that some people won't like putting the "vararg" first. 

> > port-eof? can return a bogus result if someone else is appending to the
> > file, or force peek-char to return a bogus result.
>
> That's life.
>
> Both lookahead-char and port-eof? can return misleading
> (but not bogus) results if someone else is just reading
> from the port.

> > Of less importance: to implement port-eof? at all under Unix will
> > require a "I peeked an eof" flag in the port object (because of "broken"
> > tty behavior discussed on the mailing list).

> I think the machinery for that is already required by the
> semantics of lookahead-u8.

Good points.  This raises a question: If a call to lookahead-u8 returns
eof, and the next operation on the port is a call to get-u8 or
lookahead-u8, can the second call return something other than eof if the
underlying file (or whatever) has been extended in the meantime?
(I'd say "yes".  Perhaps this is what Will meant by "misleading" rather
than "bogus" results?)

Is port-eof? just (lambda (port) (eof-object? (lookahead-u8 port)))?

> > Should we include a clear-input-port procedure?
> >  - useful in error handlers
>
> Shouldn't this be called flush-input-port?  If not, then
> I don't understand its semantics.  (You can't make
> bytes that were read previously disappear.)

clear-input-port discards any buffered input; there's no where to flush
it to.  It's useful in error handlers when reading input from the user
to avoid mistaking earlier typeahead for an answer to a query.

This is called clear-input in Common Lisp.

> > Should we include a clear-output-port procedure?
>
> I don't understand the semantics of this either.  (You
> can't make bytes that were written previously disappear
> unless the output port corresponds to something like a
> file.  Maybe a port-has-clear-port? procedure would go
> along with this.)

clear-output-port discards any buffered output.  I haven't found much use
for it.  I suppose if the computer is on fire, and you want to get the
message out quickly, you might want to discard any pending output first.

This is called clear-output in Common Lisp.

> > Why do we have only call-with procedures for bytes and string output ports
> > but only open- procedures for bytes and string input ports?
>
> Good question.
>
> I assume this was Mike's way of emphasizing asymmetry
> between input and output ports.
>
> call-with-whatever-output-port returns a useful value
> whose computation should be coupled with the closing
> of the port.  That's just my guess as to Mike's
> rationale.

Mike, if this wasn't an oversight that should simply be fixed by replacing
call-with-whatever-output-port with open-whatever-output-port, can you
explain the rationale?  Assuming there is a rationale, why doesn't it
apply to the input versions?  Why doesn't it it apply to the file opener?
Is there some reason that call-with-port won't suffice to handle all
"call-with" situations?

> > Should we include open-reader/writer-input/output-port
> > (surely with a better name)
>
> Would it take both a reader and a writer as arguments?

I guess, but I have also been ignoring the readers and writers up until
now.

Kent