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)

Re: Unreadable Objects: current status and where to go Marc Nieper-Wißkirchen 09 Dec 2022 17:30 UTC

If you stick to #<...> (the original domain of SRFI 243), you can
really only make one effective constraint, namely the following:

"A Scheme implementation supports SRFI 243 if its standard reader (and
its read/get-datum procedure(s)) signal an error/raise an exception
when the token #< is read."

(Everything else is non-normative.)  Given this specification, R6RS
systems would all support SRFI 243 and probably most R7RS systems as
well.

If you move to #?, the focus of SRFI 243 seems to change considerably.
Could you write down the intended normative part in a few sentences of
such a version of SRFI 243?

Am Fr., 9. Dez. 2022 um 18:12 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> 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.
>