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 Marc Nieper-Wißkirchen 21 Nov 2022 16:19 UTC

Am Mo., 21. Nov. 2022 um 17:04 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> > 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.

That would be good.

> > 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.

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.

> #!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.

R6RS is precise about it:  The syntax is #!<identifier>.  It counts as
a comment (but can change the reader associated with the textual
port).

You could have #!srfi-243 together with a precise description of how
`read' should behave when it is set in SRFI 243-mode.