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)

Re: Unreadable Objects: current status and where to go Marc Feeley 09 Dec 2022 19:01 UTC

> On Dec 9, 2022, at 12:11 PM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> 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.

I think the motivation is weak for having a parsable syntax for unreadable objects.  Typically one wants the reader to raise an exception when trying to read an unreadable object.  What would you want to be able to do with unreadable objects?  The SRFI spec mentions as a use case the implementation of a custom reader that skips unreadable objects.  This is rather vague… what would be achieved by skipping these unreadable objects?

If you are looking for an unused parsable syntax there is still the MIT Scheme #[…] syntax that is not used by any other implementation and that has the advantage of a “]” delimiter at the end.

Another possibility is to add a sharp sign after the terminating “>”, i.e. #<…># .  Similar to the multiline comment #|…|# .

All the other suggestions I have seen are rather ugly…

Marc