On 14-Apr-06, at 3:22 PM, Marcin 'Qrczak' Kowalczyk wrote:

> I don't like non-extensibility and non-modularity of this SRFI.
>

I understand that you might want more features.  I also want more
features (non-blocking I/O, object ports, tcp ports, soft
ports, ...).   What I'm trying to do here is to "grow an I/O system"
for Scheme based on the R5RS I/O framework.  If the spec starts out
too big it will turn off lots of people and it will not get
implemented and used.  By starting small it has a higher likelihood
of catching on, even if some people like yourself will have to wait
for followup SRFIs to be fully content.

As far as extensibility of the character encodings is concerned, one
can easily imagine an extension to SRFI 91 which allows new encoding
methods to be registered.  But that's not something I want to include
in this SRFI (in part because it is quite tricky to do right in the
presence of other features like non-blocking I/O).

> For example it understands a few character encodings. Suppose I want
> to read a file encoded in ISO-8859-2. Even if I have implemented the
> conversion itself, I can't plug it into this framework: any buffering
> to be put on top of a custom converter must be written from scratch,
> and then it's impossible to wrap it in the standard port types.
>
> It provides some encoding converters, but they can't be used to
> convert between in-memory byte arrays and strings.

This can be done if you have string ports and u8vector.  I may still
add those to this SRFI (they are not very controversial).

>
> Suppose I want to flush stdout automatically before reading from stdin
> (before the OS call; there is no need to flush before pulling data
> from
> the internal buffer). There is no place to plug that.
>
> There is no way to plug on-the-fly decompression.

As I said, nothing in the current spec prevents these things.  But
the API to get at that functionality will have to wait for another SRFI.

Marc