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 17:01 UTC

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

No-one's suggesting deprecating #!<identifier> flags, but maybe
extending the syntax so something other than an identifier can follow.

Please start a thread on srfi-discuss if you want to propose something,
as the topic is complex.

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

No language standard is practical as-is. Only people who write standards
could possibly think that.

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

May not lead to a consistent set of flags. Please talk about this on
srfi-discuss.

Too many proposals are started as SRFIS. More should be started
informally, or by talking to implementers.