Am Sa., 9. Nov. 2019 um 13:29 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > 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.

Accessors are still ordinary identifiers bound to the accessor procedure.

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

Having to add a reader switch is certainly not optimal but would be
necessary for strict R7RS-small compatibility.

As a way out, we would have to amend R7RS-small first (I guess the
Steering Commitee will have to be approached for that) so that SRFI 88
is not incompatble to R7RS-small's syntax for identifiers.

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