>> That seems true, but there has to be a reason why Kawa and Racket both
>> have keywords as syntax markers instead of actual keyword objects.
>
> https://www.cs.utah.edu/plt/publications/scheme09-fb.pdf explains the
> motivations.  Note that "PLT Scheme" means Racket.

Nice, thanks. I never grokked the difference between PLT Scheme and
MzScheme. Was PLT the distribution and Mz its VM? DrScheme was the IDE.

> I don't understand this. Nobody will use both an alist argument and
> plist-style arguments, and if some procedures use one and some another,
> that's the way it is.

That's right, each procedure will stick to one style. I meant that when
you have many procedures from many libraries, they are going to mix and
match alists, plists, records, etc; you have to memorize things and you
get no support from tools. Keyword args offer a "blessed" way to do it,
with standard syntax and semantics, and optional optimizations and read
syntax from some implementations. This also helps later with code
completion, code indexing, documentation generators, etc. "Programming
in the large" is nicer and works better when things are standardized.
The Racket team must have a big realization about that at some point.

> I'm obviously biased, but SRFI 177 needs only standard RnRS read syntax
>> while being fully compatible with all known existing native solutions.
>
> I'm not against it at all (except unnecessary uses of define-macro).

Thanks for being a stickler for hygiene. I rewrote two implementations
thanks to comments from you and Marc.

> I have every sympathy with that motivation.  I also have sympathy for
> people who will expect keyword procedures to be as fast, or nearly so, as
> non-keyword procedures, at least when the keywords are overt (not the value
> of a variable or result of a procedure).

Thanks. I still don't truly understand why keyword args need to be
blazing fast. I'll start another thread to try and ge to the core of it.

> Dybvig's idea of using identifier-syntax declarations to convert foo: into
> 'foo or 'foo: one at a time is interesting too.

You're referring to his remarks:

 > SFRI 89 can be implemented at the source level along the lines of the
code given in the SRFI description (although I would use symbol-hash to
speed up the hashing process), and a suitable replacement for SRFI 88 in
almost all cases would be to define keywords as identifier macros, e.g.:
 >
 > (define-syntax color: (identifier-syntax 'color:))
 >
 > so that the identifier color: becomes, in effect, self-evaluating.
This is actually better than having all symbols ending in colons be
self-evaluating, because a misspelling is potentially caught at compile
time.

No strong opinion on this.

Is identifier-syntax the same as a symbol macro in Common Lisp?