Discussion has settled down and there haven't been many changes
recently, so it's getting time to give SRFI-56 the thumbs up or thumbs
down, but I'm still unhappy with some things.

The library procedures provide a decent set of primitives for single
numeric values.  Other common binary I/O idioms are records and tables
of numeric values, and although they would be more efficient with their
own primitives, can at least be easily implemented in SRFI-56.

The library style of reading and writing single different sized numbers
at a time is especially well suited to such applications as writing a
portable assembler.  However, an assembler invariably needs to read and
write strings within the binary data, and SRFI-56 provides no portable
means to do this.  There are several ways to handle this inevitable
mixing of binary data and text:

  * separate procedures to write text to binary ports
    - something like read/write-utf8-string
    - Java takes this approach letting you read and write UTF-8
      characters to binary ports.
    - a complete API would need to handle all encodings.

  * procedures to convert strings to and from srfi-4 uvectors or blobs

  * separate mixed binary+text ports
    - open-binary-and-character-input-file
    - wouldn't have guarantees about buffering efficiency

  * layered ports
    - open a character port on top of a binary port, read/write a value,
      close the character port then continue using the binary port
    - flexible but more than we need for simple assembler-type cases

Without something like this it is simply impossible to write a portable
assembler.  In fact, the vast majority of binary formats include some
form of text.  If finalized as is, I'm hard pressed to think what
SRFI-56 would make portably possible that wasn't before.

I have three options at this point.  Finalize SRFI-56, and hope for
future extensions to sort out the mixed I/O mess.  In the meantime,
implementations which support mixed I/O natively would probably just do
so, leaving Java and C wchar based implementations in the cold.

Alternately I could add another quick patch.  The simplest solution is
to provide char->ucs and ucs->char procedures to convert between
characters and their Unicode code-point values.  This would make code
that needed ASCII text in binary files trivial to support, and full
Unicode could be supported by implementing your own
read/write-utf8-string or read-utf8-into-u8vector! or similar.  The
truly ambitious could implement their own encoding routines on top of
this, so at this point we do have full portability.  Convenience
encoding routines could be added in separate SRFIs.

Or, finally, I could simply withdraw the SRFI and considering writing up
a new one.  Character I/O can't properly be handled without addressing
encodings, and the specification of what an encoding is
(string, symbol or object?) and what forms and names it takes is
probably sufficient for its own SRFI.  Another missing crucial feature
for even minimal binary I/O is random access, without which one can't
even implement a (meaningful) b-tree.  At this point there would be too
many changes to band-aid onto the already long overdraft SRFI-56.

Minimality was a major goal, but has SRFI-56 fallen short of usefulness?
I've been using a SRFI-56-like library for many, many projects, but on
checking, every single one of them freely mixes binary and character I/O.

--
Alex