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 Nieper-Wißkirchen 09 Dec 2022 20:41 UTC

Am Fr., 9. Dez. 2022 um 21:14 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> One reason I can see for making giving unreadable objects a readable representation is that it makes the job of code formatters easier.  If I have a transcript of a Scheme session that includes unreadable objects in its output, my formatter can still do something helpful with it.  Just a thought.

The general transcript of a Scheme session will also include strings
printed with `display`, so the formatter already has to do some
guesswork without #<...> objects.  The job isn't much harder when
#<...> is added, I think, because the cases where the closing > is
ambiguous are rare.

That said, John's suggestion to use #<"..."> solves the point you
brought up, although when working at the REPL (where an informal
output is enough), something like #<procedure car> is a bit more
pleasant than #<"procedure car">.

Marc