Am So., 16. Aug. 2020 um 12:37 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> 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.

I don't think so because R7RS(-small) still stays as it is. The upshot
would be that R7RS-small data written by R7RS-large systems would be
unreadable by R7RS-small systems. This would go at least against the
spirit of the charter of WG 2.

A possible way-out would be that SRFI 207 defines a SRFI 39 parameter,
initially set to #f. When it is paramerized to #t, "write" and friends
may use SRFI 207 in printing. This is still an incompatible extension
to "write", but it wouldn't probably hurt much.

Marc