Email list hosting service & mailing list manager

Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 17:12 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 17:30 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 17:53 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 18:09 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 18:33 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 19:13 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 19:20 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (09 Dec 2022 19:38 UTC)
Re: Unreadable Objects: current status and where to go Arthur A. Gleckler (09 Dec 2022 20:14 UTC)
Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen (09 Dec 2022 20:42 UTC)
Re: Unreadable Objects: current status and where to go Lassi Kortela (10 Dec 2022 13:35 UTC)
Re: Unreadable Objects: current status and where to go John Cowan (09 Dec 2022 19:22 UTC)
Re: Unreadable Objects: current status and where to go Marc Feeley (09 Dec 2022 19:01 UTC)

Unreadable Objects: current status and where to go Lassi Kortela 09 Dec 2022 17:11 UTC

SRFI 243 currently attempts to clean up the traditional #<...> notation
for unreadable objects.

Marc N-W made an excellent critique of the ways in which this notation
causes parsing problems.

The problem is that the closing > is normally part of identifiers. So
#<foo bar> is ambiguous; you have to indicate the boundary between bar
and > using #<foo |bar|>.

R6RS does not have the |...| notation, and of the Scheme implementations
that do, some interpret |bar|baz as one identifier, not two.

Hence a more portable solution is #<foo bar >, i.e. a space between the
last identifier and the closing >. This looks ugly since there is no
space between the opening < and the first identifier foo. Using
symmetrical spaces, #< foo bar >, is not much prettier: since Lisp code
is virtually never written with spaces next to parentheses, the notation
sticks out.

It would also work to always wrap everything in a list: #<(foo bar)>.
But this looks ugly, too, since there are two pairs of delimiters for
something that conceptually requires only one pair.

After experimenting with S-expression variants a bit, I came to the
conclusion that (starting from scratch) a good notation would be #?foo,
where foo is any datum.

- This mirrors the RnRS #!foo notation for directives as well as the
#;foo notation for datum comments.

- The question mark is an intuitive choice to signify something that is
ambiguous or cannot be described precisely.

- #? does not seem to be used for much of anything yet.
https://registry.scheme.org/#hash-syntax says it's a "debug macro" in
Gauche; it's unused in Common Lisp.

Taking all of the above into account, I wouldn't be happy about
proposing #<foo> (any variant) for RnRS. I would be happy with #?foo
unless there are objections.

This leads to the following question:

Should SRFI 243 change course and talk about #?, or should it remain a
cleanup SRFI trying to tame the current #<...> Wild West?

As a practical matter, #<...> is in so many implementations that it will
be seen in practice for a very long time. So saying something about it
might be worthwhile, even if it can't be standardized.