Email list hosting service & mailing list manager

(Previous discussion continued)
Fwd: Re: Keywords reduced Lassi Kortela (20 Oct 2019 10:04 UTC)
Re: Fwd: Re: Keywords reduced Lassi Kortela (20 Oct 2019 10:19 UTC)

Fwd: Re: Keywords reduced Lassi Kortela 20 Oct 2019 10:04 UTC

 From Marc:

Am So., 20. Okt. 2019 um 11:29 Uhr schrieb Lassi Kortela <>:
> > Think of a procedure `loggable' on may want to implement with keyword
> > arguments. `loggable' shall take a procedure `f' and return a new
> > procedure `g', which shall have the same interface as `f' except that
> > `g' takes an extra keyword argument, say `logger:'. When `g' is called
> > without the `logger:' argument, it shall foward the call to `f''.
> > However, when the `logger.' argument is provided, `g' shall log to
> > this logger that it is calling `f' before it is doing the actual call.
> >
> > As `f' may already be a procedure taking keyword arguments, it is here
> > where hygiene is helpful because the symbol (!) `logger:' may clash
> > with an already existing argument to `f'.
> Doesn't this imply that if a program uses two different procedures
> taking a `test` keyword, each procedure from a different library, then
> the program has to rename one of the `test` keywords on import?

Yes. It is the same implication as for macro keywords we already have
in R7RS. While this may seem disadvantageous, note that such a name
clash is early noticeable by the static library system of R7RS. It has
the advantage that spelling errors are caught early.

This is not the end of the road though. Analogously to `syntax-rules'
macros (and in line of what Shiro has said), keywords do not
necessarily have to be identifiers; they could also be, say, numbers
or strings, which do not undergo hygienic renaming. So if you don't
need the hygienic renaming (and don't want to bind/export/import the
particular keyword), you can use numbers or strings instead.

One will now legitimately raise the concern that both numbers and
strings as keywords are not exactly pretty. Here, SRFI 88 will come to
our help. SRFI 88's "keyword objects" are not symbols and not
identifiers, so they will be matched by `eq?' like numbers and strings
and not by hygienically with `free-identifier=?'. They can be used in
macros wherever I want to have symbol-like markers that not matched
hygienically and could also be used in the context of procedures with
keyword arguments when hygiene is implemented with ordinary

In order to make SRFI 88 portable, I would propose a reader directive
"#!keyword-objects", which causes the reader to subsequently parse
identifiers ending with a colon as keyword object and not as a symbol.

See my SRFI 150 with hygienic record names (relevant for inheritance),
where I suggest to use keywords objects when one doesn't want/need the
extra hygiene: