Am Mi., 9. Nov. 2022 um 16:43 Uhr schrieb John Cowan <[email protected]>: > > 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 <[email protected]> wrote: >> >> On Tue, Nov 8, 2022 at 10:15 PM Marc Nieper-Wißkirchen >> <[email protected]> wrote: >> >>> >>> Thanks; you could also add Chez Scheme records for #[...]. >> >> >> Done.
