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. -- Alex