SRFI 243: Unreadable Objects
Arthur A. Gleckler
(20 Nov 2022 23:39 UTC)
|
Re: SRFI 243: Unreadable Objects
Marc Nieper-Wißkirchen
(21 Nov 2022 13:00 UTC)
|
Re: SRFI 243: Unreadable Objects
Lassi Kortela
(21 Nov 2022 13:39 UTC)
|
Re: SRFI 243: Unreadable Objects
Marc Nieper-Wißkirchen
(21 Nov 2022 13:47 UTC)
|
Re: SRFI 243: Unreadable Objects
Lassi Kortela
(21 Nov 2022 14:39 UTC)
|
Re: SRFI 243: Unreadable Objects
Lassi Kortela
(21 Nov 2022 14:59 UTC)
|
Re: SRFI 243: Unreadable Objects
Marc Nieper-Wißkirchen
(21 Nov 2022 15:51 UTC)
|
Re: SRFI 243: Unreadable Objects
Lassi Kortela
(21 Nov 2022 16:04 UTC)
|
Re: SRFI 243: Unreadable Objects
Marc Nieper-Wißkirchen
(21 Nov 2022 16:19 UTC)
|
Re: SRFI 243: Unreadable Objects Lassi Kortela (21 Nov 2022 16:32 UTC)
|
Re: SRFI 243: Unreadable Objects
Marc Nieper-Wißkirchen
(21 Nov 2022 16:50 UTC)
|
Re: SRFI 243: Unreadable Objects
Lassi Kortela
(21 Nov 2022 17:01 UTC)
|
> I didn't argue against extensions. But amending a standard through > SRFIs is a trivial task compared to amending a standard+extensions > when these extensions are not even fixed. Like all language interop, they can't be fixed without placing everything into a common framework. One of my many goals is to formalize S-expressions such that most or all the existing variants fit into a unified framework with few or no changes. This is somewhat difficult and I haven't had time to make headway yet, but it is necessary for the ongoing health of the Lisp "ecosystem". Such a framework would solve your problem, and many more besides. It would enable syntax extensions to be described precisely. And you could do formal reasoning about which extensions conflict and which don't. >> #!srfi-xyz flags would be useful, but we haven't reached consensus on >> the precise syntax. > R6RS is precise about it: The syntax is #!<identifier>. Scheme isn't R6RS. There's a laundry lit of amendments that should be made to R6RS to make it practical for modern, portable Scheme code. Nothing major, but I hope they'll be incorporated into whichever standard the current R7RS-large effort ends up being. > You could have #!srfi-243 together with a precise description of how > `read' should behave when it is set in SRFI 243-mode. IMHO individual SRFIs shouldn't say anything about these flags. They should be designed on srfi-discuss, and apply retroactively to all lexical syntax SRFIs. Perhaps once that's done, we should write one SRFI about just these flags.