This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
From: Per Bothner <per@xxxxxxxxxxx>
Subject: binary vs non-binary ports
Date: Wed, 15 Sep 2004 21:51:44 -0700
> From the draft:
> > Some Schemes may wish to distinguish between binary and non-binary
> > ports as in Common-Lisp. As these can be layered on top of the
> > current ports this may better be relegated to a separate SRFI.
>
> Huh? This is backwards. The current ports are character ports.
> As such they are layered on top of byte ports. I.e. non-binary
> ports are layered on top of binary ports.
Certainly there are implementations that inherently needs to
distinguish character and binary ports, so I see Per's point.
I can think of two resolutions.
(1) changing the phrase in the draft to mention that:
- Some implementations inherently need to distinguish character
and binary ports.
- If the port doesn't support the requested operation, an exception
is raised (already mentioned in the draft).
- The API to distinguish character/binary ports is beyond this srfi
(2) including primitive predicates, something like port-binary-io-capable?,
into this srfi, so that a portable program can be written.
> It makes no sense to mix character and binary I/O on the same port.
> Anyone who tries it is in a state of sin.
I know one instance that I need to mix both.
There are Scheme source code around that their comments are
written in non us-ascii charsets, although their code part
is in us-ascii. While dealing with such sources, it is very
annoying that the input port throws an "invalid multibyte
sequence" exception when the reader is consuming the comment
string. Using binary I/O in skipping comment avoids this
situation. It is not nice, but such robustness is mandatory
if you're in a community that exchanges source code with
comments in various encodings...
--shiro