[R6RS] I/O

[Michael Sperber]

As far as the SRFI community is concerned, I'm basically done with
SRFI 68: I've incorporated almost all of the suggestions made by
community, and the latest two revisions generated comments only on
very minor details.

Generally, the discussion was very friendly.  Some of the criticism
was on fairly intricate technical aspects, so I assume some of the
folks on the list (Shiro Kawai, Sebastian Egner, Taylor Campbell, Per
Bothner) read it pretty closely.  I'm sure there's still some details
that could use improvement, but the general concept seems pretty
solid, backed up by a reference implementation.  Any comments you
still have would be appreciated---the SRFI is still in draft.

At this point SRFI 68 (together with SRFI 74 for the representation of
binary data) fulfills the requirements we formulated in Boston, among
them:

- binary I/O
- text I/O, along with support for CRLF transcoding and for the more
  common Unicode encodings
- compatibility with SRFI 75

The unanimous agreement among the people on the SRFI list was that
R5RS compatibility was completely unimportant, as most serious
I/O-bound code needs non-R5RS functionality anyway.  This is why the
ports layer API differs from the R5RS in several respects,
specifically on argument order, default arguments, and EOF handling.

So, at this point, I request that the R6RS editors give it serious
consideration as the basis for R6RS I/O in one of several possible
forms.  Some comments on that:

- The R6RS should specify READ-DATUM and WRITE-DATUM procedures that
  succeed the R5RS READ and WRITE procedures, along with EOF-OBJECT?.
  I didn't do this in the SRFI because the exact nature of datums and
  their external representations hasn't been nailed down---but it
  should be done, and I think it's clear how.

- We should also offer R5RS-compatible I/O as a library module, which
  would be a trivial layer on top of SRFI 68.

- We might also consider adding a replacement for DISPLAY for
  quick-and-dirty debugging printouts.  (SRFI 68 doesn't have DISPLAY
  anymore, as discussed here.  Nobody seemed to want it back.)  I'd be
  in favor of finally tackling the formatted output issue to address
  this.

Here are some subsets of SRFI 68 that we might adopt for R6RS:

1. Ports layer only

This would give us a straightforward replacement for the R5RS I/O,
still fulfilling all the requirements we posed.

The ports layer is independent of the layers under it.  The
specification mentions "stream ports" that are built on streams, but
these would be elided.

2. Ports layer + primitive layer

This would allow the definition of custom port types connected to
other data sources.

3. The whole thing: Ports + streams + primitive layer

The streams layer gives you input with unlimited lookahead, along with
the ability to specify your own text transcoders (or generally
arbitrary translators).

In any case, the I/O functionality would be available as library
modules, and I suggest using the division layed out in the reference
implementation.

If it helps reach agreement, we can use one of the subsets.  On the
other hand, nobody here has offered substantial concrete criticism of
the optional parts---those that were raised here (separation of
streams and ports layer, mostly) I fixed.  The streams layer may seem
a bit progressive for Scheme, but it builds on long-established
technology in Standard ML, so I don't think anything about this
proposal is particularly radical.  So, unless somebody has substantial
criticism of the streams layer, I'd like to go with the whole thing.

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