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.