> For example, take a look at SRFI 165's "define-computation-type" and
> especially the definition of "clause" there. There, I am using the
> string "immutable" as a marker in the syntax, while an identifier
> named immutable might have been more natural. Then, however, I would
> have had to bind the identifier "immutable" and export it by SRFI 165.

Excellent argument for keyword syntax.

> Another use case is the definition of record types (especially in the
> context of inheritance):
>
> (define-record-type <rtd> (make-record field1) (field1 getter setter))
>
> Record field names like "field1" are matched hygienically as
> identifiers in SRFI 150 and in R7RS-small (at least, this seems to
> have been intended by WG1) and this has quite a number of advantages,
> but when it comes to inheriting such records across libraries, it may
> be more convenient if these record file names do not have to be ex-
> and imported. Thus SRFI 150 allows to use strings instead (ugly!) but
> proposes to use keywords (nicer!) when they are available when
> non-hygienic matching is wanted:
>
> (define-record-type <rtd> (make-record field1:) (field1: getter setter)).

This is probably good too, as long as record field accessors look the
same to users in both cases.

Record field name clashes are one of the most famous gotchas in Haskell
(https://wiki.haskell.org/Name_clashes_in_record_fields) so it's nice to
have a way to deal with them.

> If we don't want to use (or cannot use) the prefix "#'" for keywords,
> I would suggest adding SRFI 88 to R7RS-large. By default, the reader
> would read "foo:" as an identifier (to preserve compatibility to
> R7RS-small), but a reader flag to be introduced would switch the
> reader to read "foo:" as the keyword "foo:" (whose stringified name is
> "foo"). Furthermore "|foo:|" would be read as a symbol, "|foo|:" as a
> keyword.

Hmm. Optional syntax in a standardized language is a bit odd IMHO, as if
the language could not make a decision to go one way or the other. In
SRFIs and individual implementations it's fine, as those often have to
make compromises for compatibility anyway.

The #: prefix is a bit heavy at 2 characters, and Chez uses it for
gensyms. Since many implementations use : prefix or suffix, it'd be nice
to have one of those (just my opinion, and syntax is always personal).

> Thus, every Scheme port would get a flag (much like the case-folding
> flag) that can be enabled to support keywords. When enabled on output
> ports, keywords can be written. Symbols ending with ":" would be
> written using the "|...|" syntax.
>
> An extension of the port API would allow to get and set the
> case-folding and other flags on ports programmatically.

This is probably a good idea for many Scheme implementations.