> Time for some bikeshedding!

Which name to use for records - bikeshedding.

Preserving the simplicity, consistency, and clean extensibility of
Lisp/Scheme syntax - not bikeshedding.

> 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.

+1

> (As Scheme has Records and not
> Structs, I am using an R, not an S, here.)

 From
https://en.wikipedia.org/wiki/International_Organization_for_Standardization#Name_and_abbreviations:

"Because 'International Organization for Standardization' would have
different acronyms in different languages (IOS in English, OIN in
French), our founders decided to give it the short form ISO. ISO is
derived from the Greek word isos (ίσος, meaning "equal"). Whatever the
country, whatever the language, the short form of our name is always ISO."

I'm strongly in favor of using the same syntax as neighboring languages
whenever possible. However, Scheme should only use #S if the syntax is
compatible with Common Lisp #S.

> 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).

+1

> The disadvantage is that we have a limited number of letters to use after #, and we’ve already used quite a number of them.
> https://codeberg.org/scheme/r7rs/issues/9

Very important.

> This also came to my mind, but records are a fundamental concept, so
> reserving one letter for records does not seem too costly.

Everyone is prone to think their favorite concepts are fundamental :)
Imagine the next 50 years - that's a lot of time to make new additions,
especially to a large language.

Lisp is fundamentally about symbols and lists (an abstract data type of
which linked lists are one implementation). Strings and integers are
also indispensable in any language. Beyond that, it's debatable.

> 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.

I.e. represent opaque data types as records? How would this work
technically; is this explained in detail somewhere? The idea may be a
good one, I just don't understand it.

John has done good work on # extensibility in connection with the
"Twinjo" project (which is on the back burner, but definitely not
forgotten). He is using # followed by a full word instead of one letter.
I fully support this idea.

> #<...> comes from CL, where it specifically raises a lexical-syntax
> exception when read, and therefore can be used to output an object where
> an external representation is unavailable or undesirable, such as a
> stream or procedure.  It should not be repurposed for a readable lexical
> syntax.

+1. The #<...> unreadable notation has proven itself very convenient,
and should be added to standard Scheme at some point.