On 16 Aug 2020, at 12:24, Lassi Kortela <xxxxxx@lassi.io> wrote:

> From the draft:
>
> "A Scheme implementation which supports string-notated bytevectors may use this notation when the write-bytevector procedure is called, or when any of the write family of procedures is called upon a bytevector or upon another datum containing a bytevector."
>
> R7RS `write-bytevector` writes the raw bytes to a byte port, so no particular syntax will be used.

My mistake! I had read the specification and completely misunderstood that procedure. I will correct that in the next draft. Thank you!

> It's a good question whether `write` should stick to RnRS syntax or use extensions from SRFIs. We had the same discussion with SRFI 169 (underscores in numbers) and decided that `write` shouldn't use the SRFI.
>
> Someone had the clever idea of using the SRFI's syntax for `display` (since it's well-known and deliberately specified that `display` output is not always readable by `read`), but sticking to RnRS syntax for `write` which is stricter.
>
> A configurable Scheme printer akin to the one in Common Lisp would be useful, but I don't think we have a SRFI about that yet. The recent monadic formatting and combinator formatting SRFIs go in that direction.

Then we have a precedent against my proposal’s permissive use of this notation by the writer in implementations whose reader supports it. And also from SRFI 169 a negative precedent for my question about whether or not an import should be required before using this fancy notation.

That said, I expect that this SRFI (if it goes all the way to final) will go on the ballot for R7RS-large when notational issues come to be considered. So objections about not being RnRS-compatible arguably go away then.

Daphne