[R6RS] Unhappy about I/O

Michael Sperber sperber
Mon Dec 12 16:09:13 EST 2005

As y'all may have noticed, I've split the I/O SRFI into four parts, as
requested by Marc and several other people in the community.  They

Primitive I/O:

Stream I/O:

Port I/O:

Stream Ports:

Specifically, SRFI 81 is a replacement for the R5RS ports I/O, and
fulfills the requirements we formulated in Boston.  (It fulfills a few
more such as the ability to create custom port types, but these can
easily be excised should anyone fill the need.)  Specifically, it has:

- binary I/O
- support for the most common Unicode text encodings, compatible with
  our Unicode spec

It does pull in SRFI 74 (Octet-Addressed Binary Blocks), but could
easily be changed back to depend on on the simpler SRFI 66 (Octet
Vectors), if anybody here feels that SRFI 74 hasn't been disseminated

As splitting it up was the last of the concerns raised for the
original SRFI 68 I felt I could address at the time, and as Donovon
Kolbly has done pretty thorough editing (by my book, anyway), the only
changes I have in the queue currently are clarifications to the spec.
(The proposal also doesn't have READ and WRITE, but that doesn't mean
I want to leave them out---they're just outside the purview of that
particular SRFI, and I felt it didn't make much sense to pin those
down more, as we'd planned, without knowing what the datum spec would

At this point, SRFI 81 (Port I/O) is my candidate for inclusion in
the library part of R6RS.

The SRFI is currently suffering from a lack of specific comments by
the R6RS editors---I feel I've done everything in my power to present
the proposal (including keeping you posted on updates, preparing a
presentation at the Boston meeting, and giving that presentation to
Kent and Will personally) in a timely manner and in accordance with
our plans and address the comments people have made, including the
ones made by Manuel and Marc earlier this year.  

There were quite a few comments, and many of them with constructive
suggestions I've been able to incorporate.  (Not all of them,

Marc has commented on the overall concept here


but I've so far not managed to understand how they relate to the
proposal at hand.  My own reply is here:


No response yet.

Needless to say, I'm really unhappy at this point.  I've received
comments and personal encouragement from a few of you in person, but
very little is documented on the list.  Nobody has answered my request
for clarification on whether I/O is even still within the purview of
R6RS, as re-affirmed at the Boston meeting.  Marc also hasn't answered
any of my repeated queries over the past few months on how he thinks I
should proceed.  So I'm asking all of you to please comment on the
proposal (either here or on the SRFI list), or to say that you're
happy to leave it to me or someone else, or make any kind of
suggestion on what to do.

Marc posted the I/O chapter from the Gambit-C manual as a proposal
earlier this year---if you think it would be beneficial if I commented
on it (in my view, it has several substantial drawbacks), I'll do so.
I've objected to that for procedural reasons, but if anyone thinks it
helps, I'll do it.

If you don't agree or if you think I'm out of line (certainly
possible), please let me know.  At this time, I'm pretty desperate for
*any* kind of comment.

I realize the fact that I've put a lot of work into the proposal
doesn't, in and of itself, warrant dissemination by the R6RS editors.
On the other hand, I've always announced my intentions way in advance,
and nobody ever told me I was unwarranted in the assumption the
proposal would eventually become part of our discussion.  Given the
long lapses of activity on the list, not having enough time amidst all
the other R6RS work is hardly an excuse.

Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla

More information about the R6RS mailing list