[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: binary vs non-binary ports
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
> > 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.