External representation
Marc Nieper-Wißkirchen
(06 Nov 2022 16:40 UTC)
|
Re: External representation
Shiro Kawai
(06 Nov 2022 21:03 UTC)
|
Re: External representation
Marc Nieper-Wißkirchen
(06 Nov 2022 21:23 UTC)
|
Re: External representation
Lassi Kortela
(06 Nov 2022 21:29 UTC)
|
Re: External representation
José Bollo
(08 Nov 2022 20:48 UTC)
|
Re: External representation
Marc Nieper-Wißkirchen
(08 Nov 2022 20:53 UTC)
|
Re: External representation
Arthur A. Gleckler
(09 Nov 2022 00:39 UTC)
|
Re: External representation
Marc Nieper-Wißkirchen
(09 Nov 2022 06:15 UTC)
|
Re: External representation
Arthur A. Gleckler
(09 Nov 2022 07:38 UTC)
|
Re: External representation
John Cowan
(09 Nov 2022 15:43 UTC)
|
Re: External representation
Marc Nieper-Wißkirchen
(09 Nov 2022 15:59 UTC)
|
Re: External representation
John Cowan
(09 Nov 2022 16:42 UTC)
|
Re: External representation Marc Nieper-Wißkirchen (09 Nov 2022 17:19 UTC)
|
Re: External representation
Lassi Kortela
(09 Nov 2022 16:03 UTC)
|
Re: External representation
Marc Nieper-Wißkirchen
(07 Nov 2022 09:58 UTC)
|
Am Mi., 9. Nov. 2022 um 17:42 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > > > On Wed, Nov 9, 2022 at 10:59 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: > >> >> Only the names of condition types use the ampersand as a prefix > > > That's true, but I took it to be an accidental consequence of the fact that R6RS does not standardize any record types other than (simple) condition types. I see, however, that there are some examples in library section 6.2, none of which have ampersands. By the way, there is a good reason none of the record names in library section 6.2 have ampersands: Otherwise, the automatically generated constructors, for example, would be called "make-&point", etc. (Note that define-condition-type, a syntactic layer over define-record-type, does not construct new identifiers, but all have to be given explicitly.) >> And for record names that actually start with an ampersand, there >> would be an unfortunate doubling of ampersands: #&(&message "a stored >> message condition"). > > > I think that is extremely minor. >> >> Anyway, #& is already used; see your SRFI 111, where you collected >> existing lexical syntax for boxes. > > > True; I forgot about that. > >> The idea is that #!srfi-237 is a comment as far as the lexical syntax >> and its transcription into syntactical data is concerned. Moreover, >> when a reader supporting SRFI 237 reads it, it must enable the >> external representation of records described in SRFI 237 on subsequent >> input and may, therefore, have to disable conflicting >> implementation-specific lexical syntax. An implementation not >> supporting SRFI 237 should signal a reader error. > > > Okay, please use this language (vel sim.) instead. Noted! I will make the change before the next draft. I hope your issues concerning the usefulness of #!srfi-237 are addressed.