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.
On 8/23/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Yes, SRFI-68 can easily handle all of these issues, simply using > > READ/WRITE-U8 for READ/WRITE-BYTE. This is because SRFI-68 makes no > > distinction between binary and character ports. [...] > > I don't quite understand what you mean here---it's true that you > probably can't use the underlying abstractions for text I/O, but you > certainly can perform text I/O using the facilities in SRFI 68, > building on the underlying binary I/O. Trying to build a > multi-encoding text I/O system that's magically compatibly with what > the common platforms have (i.e. the common implementations of wchar, > .NET, Java etc.), and still functionally desirable is hard, and I have > trouble seeing the benefits. Per addressed whether this is desirable or needed, and I think that discussion is better left to the SRFI-68 list as he suggested. Granted, compatibility with existing platforms is difficult, but it's far from impossible. I've already suggested four broad categories of solutions that could be used, and my worry now is simply that it seems like too much of a last-minute change and hasn't been thought out from the beginning. > > Another way of looking at it is that SRFI-68 is flexible enough to allow > > us to create new port types with an explicit binary vs character > > distinction. > > That distinction is really anathema to its design approach---see the > Design Rationale section. I wasn't actually suggesting Schemes supporting SRFI-68 voluntarily restrict themselves in this manner, I meant rather to show what the problem is along with a more concrete solution implemented using SRFI-68, like using a hash-table to implement a vector. -- Alex