This SRFI appears to be stuck.
Lassi has told me that he has an idea for how to make progress with
this SRFI. I'm waiting for him to provide a new draft.
I apologize for the huge delay with finishing up this SRFI.
I agree that there is too little to say that would be technically novel
about the #<...> lexical syntax. Meanwhile, most of you didn't like the
idea of a new lexical syntax.
Consequently, I will retarget the SRFI to not mandate any particular
lexical syntax, and simply to make the behavior of `read` and `write`
more precise.
The implementation can use any lexical syntax it likes for unreadable
data, and shall raise a particular type of error upon encountering it.
A distinction is made between:
- An "unreadable object", meaning we can read a stand-in object and skip
past it to potentially read more objects. For example, in the syntax
#[procedure append], the stand-in object would be the two-element list
[procedure append] -- assuming a Scheme implementation in which [...]
brackets are list delimiters. Unreadable objects can be nested, because
that's simpler than forbidding nesting.
- "Unreadable data", meaning we can skip past a marker (conventionally
"#<") that starts the data, but after that you are on your own. A
hypothetical reader might `read` until the marker and then `read-string`
the rest, for example.
If `write` writes "unreadable objects" and not merely "unreadable data",
then the implementation can make the elegant guarantee that `write` will
always write out a self-consistent data structure (even in cases where
it cannot preserve read-write invariance). The SRFI will encourage but
not mandate this.
I have a patch for STklos, and another patch against Göran's "laesare"
reader. I'll submit these and a draft as soon as I can.
