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)
|
> You amend the lexical syntax of RnRS, but the examples don't comply > with this amendment. They would only comply with a version of your > amendment tailored to the specific implementation. It's implied that implementations straying from the RnRS grammar should make equivalent additions to their own reader. I thought this was taken for granted, but since not I'll add an explicit note to the next draft. > Hooray to R6RS, which is clear about what `read' has to parse and when > `read' has to raise an exception. While it's good to have the #!r6rs flag to enforce "the standard and nothing but the standard", extensions are equally useful. R6RS doesn't have |vertical bar identifiers|, for example. That causes practical difficulties. #!srfi-xyz flags would be useful, but we haven't reached consensus on the precise syntax. There has been at least one thread on srfi-discuss about it.