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