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 15:59 UTC

Am Mi., 9. Nov. 2022 um 16:43 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> On reflection, I think the Right Thing (if there is going to be lexical syntax for records at all) is #&(...).  In R6RS, the names of records begin with & by convention, and #& is not used for anything in any Scheme, at least based on the existing tables.  This is a little more verbose, but it is fairly clear.

Only the names of condition types use the ampersand as a prefix, so
there is not really a connection to a general record type.

And for record names that actually start with an ampersand, there
would be an unfortunate doubling of ampersands: #&(&message "a stored
message condition").

Anyway, #& is already used; see your SRFI 111, where you collected
existing lexical syntax for boxes.

> "The lexical syntax #!srfi-237 indicates that subsequent input may contain external representations of records as defined here. Otherwise, it is treated as a comment" is not really coherent.  In what circumstances is  #!srfi-237  to be treated as a comment?  As written, it seems to mean that it is a comment if it is not present.  If the word "otherwise" is deleted it makes a little more sense; that is, it is always a comment, but warns the (Scheme) reader that lexical syntax may appear.

I used the language from the R6RS, which is apparently misleading.

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.

Does it make more sense now?

Thanks,

Marc

> However, what good is that?  If #&(...) is present but not understood, it should be treated as an error, whether SRFI 237 is supported or not.  The rtd read flag can be used to suppress interpretation of record lexical syntax for safety reasons, but it makes no sense to rely on a feature of the file being read to protect against unsafe record lexical syntax.  If there were a competing semantic for &#(...), then it would make sense to turn it off with  #!srfi-237 , but there is not.
>
> On Wed, Nov 9, 2022 at 2:38 AM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>>
>> On Tue, Nov 8, 2022 at 10:15 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>>
>>> Thanks; you could also add Chez Scheme records for #[...].
>>
>>
>> Done.