+1 on the SRFI.
Thanks!
1. [Flushed with pride] It's entirely
possible that a custom port might need to do something special when it
is flushed (e.g., refresh a screen region). I would suggest, therefore,
that a trailing optional flush argument be permitted. flush-output-port
will therefore call that procedure, or do nothing (if it's omitted or
#f).
That's compelling, and I'll add it.
2. [Bidirectional ports] R6RS defines input/output ports,
Not as such: it only says that a port may satisfy both input-port? and output-port?, which is equally true in R7RS. I made sure that read, write, etc. take a simple port argument.
There are good reasons for eschewing them on files (the
semantics of a port for randomly reading and writing a file---a
practice fortunately much more common in the Long-Ago than now---are
quite different from those of a port that provides input from and output
to a terminal).
I disagree with your "fortunately"; I think the technique of fixed-length records is a perennial, though the domain of its use cases has shrunk. But you are right that it doesn't and can't work on everything, because it depends on the ability to seek.
However, custom input/output ports would still be very
useful, with the issues of port semantics left to the port's designer.
I'd therefore argue for their inclusion as per R6RS
Agreed (modulo they aren't in R6RS). There are two possibilities: accepting both a read! and a write! argument (MIT-ish), and accepting an input and an output custom port and returning a bidirectional port (Chicken). I'm inclined to go for the first.
MIT actually accepts an arbitrary number of callbacks in an a-list, and has a function to call any custom operation. That is perfectly general, but perhaps too general for utility.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThey tried to pierce your heart with a Morgul-knife that remains in
the wound. If they had succeeded, you would become a wraith under the
domination of the Dark Lord. --Gandalf