Am Mo., 21. Nov. 2022 um 14:38 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > there only seem to be "shoulds" and not "musts" in the specification.
>
> Not so: the grammar extensions and reader behavior are a must.

Then I don't understand; an implementation (conforming to R7RS)
already has to signal an error when it comes across an unreadable
datum, which is "#<...>" in standard Scheme.

>
> > Your examples show that the Schemes in existence don't follow SRFI
> > 243's recommendations.  For example, something like XXX#YYY is not the
> > written representation of a datum.  Moreover, if you type "<" instead
> > of "+" in the Chez Scheme REPL, you see that the angle brackets are
> > not usually paired.
>
> In standard Common Lisp, angle brackets are not universally paired
> either. They are only paired in #<...> syntax.
>
> In Scheme, <...> are conventionally paired in the names of types,
> particularly record types and OOP classes.
>
> SRFI 243 doesn't ascribe any meaning to "<" and ">" outside the
> particular syntax #<...>.
>
> Only readers who need to skip past #<...> datums actually have to parse
> the paired delimiters. Normal readers are free to stop at #< and raise
> an error without reading any further.

I am talking about "<" inside #<...>.  From the Chez REPL:

> <
#<procedure <>

(The first ">" is the prompt, of course.)

> The sample implementation parses '> symbols, but it is cheating. A
> serious reader that skips #<...> would not do that. It would instead use
> an equivalent of read-delimited-list in Common Lisp
> (http://clhs.lisp.se/Body/f_rd_del.htm). That function reads a proper
> list except that the closing bracket is different.

> > Adding something like "<...>" to <datum> in the Scheme grammar doesn't
> > look like a particularly good idea because, by R7RS, <datums> are what
> > the reader successfully parses, and each <datum> must come with a
> > mapping to Scheme values.  But SRFI 243 doesn't define corresponding
> > values.
>
> That's the whole point of the SRFI.
>
> - A datum is a standalone representation of an object, but not all
> objects can be represented standalone.
>
> - You need to be able to (write) those objects somehow, so we write
> #<this stands in for something that is too difficult to write>.
>
> Instead of reserving the #<...> syntax you could also make (write) raise
> an error. I haven't heard of any Scheme (or Lisp) implementation that
> does that. The ability to print _some_ information about an unreadable
> object is useful, even if you can't preserve read-write invaraiance.
> This is particularly true when #<...> is nested in another object. If
> (write) raised an error, the outer object could not be printed at all!
> IMHO it's clear that #<...> is the lesser evil.
>
> Instead of #<...> it could be #unreadable(...). But since #<...> is an
> extremely widespread part of Lisp and Scheme tradition, I'd prefer to
> honor the tradition.
>
> Note that turning #<procedure foo> and #<port bar> into #procedure(foo)
> and #port(bar) is not a good idea since the latter notation suggests
> that you can read those objects back in.
>
> > What would (foo . #<unreadable>) be for a Scheme reader that
> > "skipped" #<...>?
>
> Some such readers would simply ignore all expressions containing
> unreadable stuff, as if those are whitespace.

So

(foo . #<unreadable>))

would be (foo .) and thus an error while

(foo #<unreadable>) would be (foo) and thus not?

This looks strange to me.

>
> Some such readers would have an "unreadable" pseudo-object-type, and
> read the stuff between #<...> into it. Perhaps it would want to wrap an
> outer expression containing unreadable sub-objects in a special
> container, but probably not.
>
> See Weinholt's "laesare" library for one reader that might want to do
> something like this.
>
> You're generally concerned about standard Scheme semantics. In that
> case, #< would just be a read error.

You haven't answered the point about the XXX#YYY syntax, have you?