[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why are byte ports "ports" as such?

This page is part of the web mail archives of SRFI 91 from before July 7th, 2015. The new archives for SRFI 91 contain all messages, not just those from before July 7th, 2015.

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