Re: binary vs non-binary ports

[Alex Shinn <foof@xxxxxxxxxxxxx>]

At Wed, 15 Sep 2004 23:54:51 -0700, Per Bothner wrote:
> 
> Existing APIs (Java, C++, C) disinguish byte I/o from chracter I/O,
> generally using different types.  They may not support easy on-the-fly
> switching between binary mode and character mode.

C API's distinguish between char and wchar operations acting on the
same underlying port.  The SRFI-56 API exactly models this, and C is
by far the most commonly used language to implement Scheme.  If Java
does not allow a similarly simple implementation of these primitives
then that is unfortunate, but may be thought of as a reflection of the
fact that Java is not a systems programming language and thus not as
well suited to implementing other programming languages.

> > I work very often with binary file formats, including Scheme libraries
> > for handling ELF, TIFF, and the gettext .mo format among others.
> > Every one of these mixes binary and character data.
> 
> I did not say character data - I said character I/O.  It is perfectly
> feasable to read/write character and string data from/to a binary
> stream - but then you have to define how they are encoded or do the
> mapping before/after you write/read them.

Yes, this is a tricky issue, but it exists regardless of whether or
not you specifically tag the port as being meant for character I/O or
binary I/O.

> > 3) Extract character data in binary ports as binary first then convert
> >    with utility procedures to character/string.

> Yes, conceptually that is what should be going on.  But if you want to
> be able to do binary I/O on an arbitary port (that was opened in default
> mode) then that constrains the implementation unacceptably.  Existing
> code that implements ports may have to be extensively rewritten.

And existing code that implements ports may have to be extensively
rewritten if operations like read-char are not allowed on all ports.
If you want to average the amount of work generated across all major
Scheme implementations then I suspect the current approach produces
the least amount of work.  But I'd really prefer to focus on the
practicality of the end result than on the implementation details.

-- 
Alex