My only add here is that I implemented SRFI 88 & 89 for my own system.   88 is optional and enabled with #!srfi-88  and can later be turned off with #!no-srfi-88.  They set/clear a parameter associated with the port being read, in a manner consistent with #!fold-case and #!no-fold-case.

I don't actually use the keyword functionality that often, mainly because of little support in the community, though I do like to use define* and lambda* from (srfi 89) for optional argument handling.    Where syntax-rules macros use strings as literals in patterns to trigger internal states, srfi-88 keywords are slightly nicer because they compare faster.   Of course there are good reasons for library code to use "private" identifiers for this purpose.      But where we have had the debate of whether some syntax should to symbolic-matching vs. syntax-rules-style literal-identifier matching, I often wonder if the using keywords would simplify life in situations where the symbolic (eq?) matching makes more sense.

The most common incompatibility I run into is syntax-rules code that uses ::: as an alternative ellipsis, which must be an identifier.

On Sun, Jul 21, 2019 at 4:47 PM John Cowan <> wrote:

On Sun, Jul 21, 2019 at 5:30 PM Amirouche Boubekki <> wrote:

What I was thinking about this topic, is not introduce another datum
like :keyword
or #:keyword but instead create some argument parser procedure like used
for command line arguments. This is backward compatible and build upon existing

There are several such parsers; they are independent of whether keywords are self-quoting or just plain symbols.  I just sent out the description of (chibi optional), which is meant to work with ordinary symbols that you have to quote.  Standardizing such a library is probably a Good Thing; whether we should standardize self-quoting symbols, and in what shape, is the issue right now.

John Cowan
If I read "upcoming" in [the newspaper] once more, I will be downcoming
and somebody will be outgoing.