On 8/23/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> 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