I did some digging. I've re-read the R6RS docs, and the Larceny, Racket, Ikarus, & Chez sources. I picked these older implementations because it's more likely their maintainers were involved in R6RS discussions. Additionally, I tested Guile.The R6RS docs give no indication under what circumstances write! would be passed a zero-length buffer. One might guess that a put-bytevector with zero length may have been the intended trigger. The requirement in question is on the users of (SRFI 181), not the implementation. There is no requirement in R6RS or this SRFI on the implementation to invoke write! with a zero count.Larceny, Ikarus, Chez, guile -- I've skimmed their sources and unless I missed something, I see no way write! would ever get called with a zero count. They all add a buffering layer on top of the custom methods when building the port and only non-empty buffers are passed to write!. Guile has lots of tests, some of which confirm that write! is NOT called with a zero count, and no tests to confirm that a zero count would or should occur.Racket does not provide make-custom-*-*-port at all.I ran tests with Chez, guile, and larceny - none could demonstrate a call write! with a zero count. I was able to enable buffered vs. unbuffered modes in chez & guile, also no zero-count calls. I was unable to build or find an ikarus executable to test.Conjecture about motivations of the clause -- if the custom port was intended to convey line-discipline semantics (ie a tty), or datagram semantics, it might be useful for a put-bytevector of length zero to be reflected as something distinguishable on the receiving end. Alternatively, perhaps the author was erroneously aiming for symmetry with POSIX's read system call where zero bytes received indicates EOF.I would prefer to see those clauses scratched from the SRFI, and doing so does not inhibit any existing implementation from being conformant. On the other hand, the clause does not mean anything until an implementation has a reason to apply the situation, so their presence doesn't really do any harm -- they just look wrong to me.On Wed, Mar 4, 2020 at 7:36 PM John Cowan <xxxxxx@ccil.org> wrote:I confess I have no idea: that text comes verbatim from R6RS, so someone more versed in R6RS than I should answer. It is a rather dark corner of the language, I think.On Wed, Mar 4, 2020 at 2:31 PM Jim Rees <xxxxxx@gmail.com> wrote:In reference to the write! method requirements:"... If count is 0, the write! procedure passes an end-of-file object (or equivalent) to the byte sink. "
"... If count is 0, the write! procedure passes an end-of-file object (or equivalent) to the character sink."Can you explain under what circumstances this would occur? What output port operations would/should trigger this?On Sun, Feb 16, 2020 at 3:03 AM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:Scheme Request for Implementation 181,
"Custom ports,"
by John Cowan,
is now available for discussion.
Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-181/.
You can join the discussion of the draft by filling out the subscription form on that page.
You can contribute a message to the discussion by sending it to xxxxxx@srfi.schemers.org.
Here's the abstract:This is an extract from the R6RS that documents its support for custom ports. These provide a hook into the Scheme port system from below, allowing the creation of binary and textual ports that behave exactly like file, string, and bytevector ports, but whose basic operations are provided by user code. It has been lightly edited to fit R7RS style.
Regards,
SRFI Editor