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:31 UTC

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

Like all language interop, they can't be fixed without placing
everything into a common framework.

One of my many goals is to formalize S-expressions such that most or all
the existing variants fit into a unified framework with few or no
changes. This is somewhat difficult and I haven't had time to make
headway yet, but it is necessary for the ongoing health of the Lisp
"ecosystem".

Such a framework would solve your problem, and many more besides. It
would enable syntax extensions to be described precisely. And you could
do formal reasoning about which extensions conflict and which don't.

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

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.

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