Email list hosting service & mailing list manager

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)

Re: SRFI 243: Unreadable Objects Lassi Kortela 21 Nov 2022 16:04 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.