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 Lassi Kortela 10 Dec 2022 13:35 UTC

> The general transcript of a Scheme session will also include strings
> printed with `display`,

Yes

> 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.

I've worked with code formatters a lot. Making them do guesswork about
syntax means something is badly wrong in the design. Formatters should
work with "write output", not "display output".

> 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">.

#<"string"> is heading in the direction of Unix where syntax and parsing
tends to be ad hoc. We should go in the opposite direction, of Lisp,
where the trend is for all data to be structured and uniform.

SRFI 176 has already delivered on this front. We should do more. I'll
write that essay, "Taking S-expressions seriously", in due course.