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