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 09 Dec 2022 19:38 UTC

> It is only "fundamentally broken" if you want that what comes between
> #< and > to be readable using standard Scheme lexical syntax.  I am
> not convinced that the latter is an important point.

I think (write foo) should always write a self-consistent structure.
Only strings and comments should be unstructured data.

The examples in SRFI 243 show that there is already a general trend to
write something almost structured. Why not go the last mile?

In a similar vein, R7RS (display foo) to use either (write) or (display)
to write nested strings, characters, symbols. If an implementation uses
(display), the output is a weird mix of structured and unstructured
data. IMHO nested data should always use (write) syntax.

These are points of aesthetics and uniformity. Those tend to be
immediately useless, but tend to have useful long term consequences. I
have a general long-term interest in using S-expressions in more places,
more consistently and comprehensively; perhaps the present topic can be
understood in that light.