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)

Re: External representation Marc Nieper-Wißkirchen 09 Nov 2022 17:18 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.