On Wed, Mar 4, 2020 at 9:48 AM Jim Rees <xxxxxx@gmail.com> wrote:

If we are to honor R7RS, with u8-ready? and char-ready?  I think we are obligated to support their implementation in custom ports as well, otherwise, we are declaring those procedures deprecated and useless (which may be a valid decision).

No, we are simply admitting that the port abstraction is a leaky one and that not all operations work on all ports.  As things stand, Chibi implements char-ready? as u8-ready? and does not attempt to find out if the trailing bytes of a multi-byte UTF-8 character are available.  Chibi does not have a general I/O multiplexer (which would be difficult to fit in with its use case as an embedded Scheme) and simply calls poll() on the single relevant fd.

If I add non-trivial features to this SRFI, the set of available implementations drops from "all R6RS systems" to "none".  I am not eager for that to happen.  I will add flush as an optional argument to the make-custom-port procedures with a warning that it may not be called on all systems.

I am considering adding the MIT Scheme feature of custom operations: a custom port is defined with an optional alist mapping operation names (arbitrary symbols) to procedures, and then there is a user-level (port-operation port name) that pulls procedures out of the alist.  But even that may not provide enough bang for the buck, as it has to be specified in such a way that it may return #f, just like flush.

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
The man that wanders far from the walking tree
        --first line of a non-existent poem by me