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)
|
Am Mo., 21. Nov. 2022 um 17:31 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > >> #!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. R6RS *is* a Scheme standard and the only one saying something about the general #!<identifier> syntax. My point here is mainly that we shouldn't have to reinvent the wheel when it is already invented. We should only reinvent obviously broken wheels. > 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. R6RS *is* practical for modern, portable Scheme code. It was designed as such. Some will disagree, but then the current R7RS is even less practical. > > 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. I don't see why it is necessary to postpone this (possibly after the last SRFI will have been written). A hypothetical flag #!srfi-243 will certainly not be used by any other SRFI.