The external representation for records used by many implementation of Scheme is the syntax #<name ...> .  Wouldn’t it make sense to use that syntax?

It isn’t clear what purpose the external representation will serve.  It could be just for debugging, or to have a write/read invariance of records (for saving/restoring objects from files for example).  Write/read invariance is a much more complex feature, especially if the records are generative, but also if the Scheme implementation has added features to records such as inheritance and hidden fields (very useful if you have circular structures such as a “parent” field in a tree node).

For debugging it is convenient to have the names of the fields as part of the external representation.  A record with more than 3-4 fields becomes difficult to read (for humans) when there are no names next to the fields.

Moreover, I find it very convenient for debugging to assign serial numbers to records (and other not-necessarily-readable objects) so that they can be referenced at the REPL to get the exact same object back (not a copy).  Here’s an example at the Gambit REPL:

 > (define-type point x y)  ;; a generative record type
 > (define rect (list (make-point 11 22) (make-point 33 44)))
 > rect
 (#<point #2 x: 11 y: 22> #<point #3 x: 33 y: 44>)
 > (point-x-set! #2 999)  ;; reference the first point in the list using #2
 > rect
 (#<point #2 x: 999 y: 22> #<point #3 x: 33 y: 44>)
 > (lambda (x) (* x 2))
 #<procedure #4>
 > (#4 100)
 200

Note the use of #N to refer to the object wih serial number N.  The serial number of objects are generated lazily (when the object is written) and they are kept in a weak hash-table so they are generally valid until the object is no longer reachable.  The #N notation does not conflict with #N= and #N# that is used for representing cycles and sharing (as long as the character = and # don’t follow the N a #N is a reader macro that expands to (serial-number->object N) ).

Write/read invariance of records (and other typically not-readable objects) is achieved by setting the input/output port to a special mode because this is typically not what you want for casual writing of data.

Marc

> On Nov 15, 2022, at 6:20 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Di., 15. Nov. 2022 um 11:54 Uhr schrieb Daphne Preston-Kendal
> <xxxxxx@nonceword.org>:
>>
>>> On 15 Nov 2022, at 09:40, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>>
>>> On the other hand, given the existing notations for bytevectors,
>>> #vu8(...) and #u8(...), the lexical syntax
>>>
>>> #r(uid field ...)
>>>
>>> may make more sense for records.  (As Scheme has Records and not
>>> Structs, I am using an R, not an S, here.)
>>>
>>> The latter syntax has the advantage that it does not rely on a
>>> difference between parentheses and brackets (which are, otherwise,
>>> equivalent, at least in R6RS).
>>
>> The disadvantage is that we have a limited number of letters to use after #, and we’ve already used quite a number of them.
>
> This also came to my mind, but records are a fundamental concept, so
> reserving one letter for records does not seem too costly.  After all,
> by using the record syntax, one can possibly get rid of a lot of
> otherwise needed lexical syntax.
>
> E.g., instead of reserving "#&<datum>" for boxes, one could simply
> write "#r(box <datum>)" (when we reserve the uid "box" for SRFI 111
> boxes).
>
> In fact, I would suggest reserving record uids that are not of the
> recommended R6RS form <name>-<uuid> for the standard.  This opens up a
> whole new namespace for written representations.
>
> Also, note that hypothetical prefixes like #r8 or #ru16 would still be
> in the list of not yet reserved prefixes.
>
>> https://codeberg.org/scheme/r7rs/issues/9
>>
>> Daphne