[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: binary vs non-binary ports

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.

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.