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.

Reply via email to