Am Di., 13. Juni 2023 um 21:59 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > A couple of comments:

More comments:

0) The SRFI contains the sentence "A Lisp system can be asked to write
any live object as an S-expression.".  If "S-expression" here means
"textual representation" of an object, then the answer is generally
"no", at least for R6RS systems because "write" may raise an exception
for a non-datum value.

>
> Thank you for the thorough reading! (No pun intended :-)
>
> > 1) What is meant by "well-formed S-expression"?
>
> Something that can be read back in.

This is too arbitrary, isn't it? Any sequence of characters can then
be viewed as a well-formed S-expression.  The same holds for the
"binary" version below.  It seems to me that the term "S-expression"
is used excessively. If the term has no well-defined meaning in the
context of SRFI 243, better drop it and describe the problem and the
solution with terms defined in the RnRS or other SRFIs.

> > What is a "binary S-expression"?
>
> For example this repo <https://github.com/lispunion/database-subprocess>
> uses them to talk between Scheme and a SQLite subprocess written in C.
>
> Rivest's proposal https://datatracker.ietf.org/doc/draft-rivest-sexp/
> could be construed as binary.
>
> There are probably others.

[...]

> > 3) The SRFI is probably incompatible to R6RS because R6RS's
> > read/get-datum must raise a lexical error as soon as an invalid
> > character is encountered while datum syntax is read.
>
> That's only in #!r6rs mode?

Then the SRFI should say a word about a necessary #!... flag.

> In any case, the SRFI should probably say that new &unreadable condition
> type is a subtype of the standard &lexical type.

Ok.

>
> > 4) How are cycles/shared data structures going through unreadable
> > objects handled?
>
> Depends entirely on the implementation.

I have the feeling that the SRFI again specifies not enough.

[...]

> > 6) The usefulness of the SRFI is not yet clear to me.
>
> This is a frequent complaint about SRFIs in general. I'm not sure I can
> make the rationale clearer than it is without unduly expanding it.

A SRFI should either

(a) describe a problem and provide a solution

or

(b) describe an area where Scheme is more complicated than necessary
and provide a simplification (e.g., by generalization)

or

(c) make Scheme more expressive as a programming language.

SRFI 243 does not belong to category (b) and (c) as far as I see it.
As for (a), not even the problem SRFI 243 tries to solve is clear to
me. It is not about interaction with the user (because Scheme systems
already handle this well), nor is it about data exchange (because no
lexical syntax is guaranteed). And even if it were about the exchange
of (partial) data, a much simpler and more general solution would be a
SRFI that provides a procedure (datum-map <PROC> datum) that handles
cycles in lists and vectors so that a user could write something along
the lines of (write (datum-map (lambda (x) (if (atom? x) x (substitute
x))) obj).