To get back to Marc's very good points earlier:

> The reasons why I have been a bit reserved may be
> the summarized by the following (and, maybe, this can still be
> addressed in a revised version of SRFI 177):
>
> (1) Premature "standardization" of procedures with keywords. SRFI 177
> is a compatibility layer over several native keyword systems (and a
> fallback system). The semantics and syntax of SRFI 177 has been
> dictated to make it implementable just with `syntax-rules'.
>
> Thus, the semantics and syntax of SRFI 177 are probably far from
> optimal if we had the chance to devise it from scratch (as opposed to
> be a common denominator, portably implementable in R5RS). Should ever
> become procedures with keyword arguments candidates for inclusion into
> R7RS-large (or some other future standard), we should be free to
> invent semantics and syntax that may be incompatible with SRFI 177.

It's true that the needs of SRFI 177 have been driven entirely by
compatibility. It's a "lowest common denominator" thing.

Luckily we have a list of possible directions where keywords could go:

- Keywords-as-objects vs keywords-as-markers (Kawa, Racket). Both need
to be supported, and currently are.

- Keywords being global symbols vs hygienic identifiers. Both can be
supported if the distinction is made using symbols vs keyword objects.
Since all implementations with native keywords currently use global
keywords, 177 definitely needs to support that alternative. It would be
nice if 177 can also support hygienic keywords, but since 177 is a
lowest-common-denominator compatibility syntax, it's not a requirement.
If another SRFI (or RnRS) has another syntax that allows hygienic
keyword arguments, and the 177 macros expand to something compatible,
then code using 177 and code using the future richer syntax can be mixed
freely. Eventually, many years down the line, 177 can be phased out.

- Required keyword arguments; default values (other than #f); supplied-p
parameters ala Common Lisp; combining keywords with optional positional
args and rest args. Every one of these things is already supported by
the `lambda` or `lambda*` of one or more Scheme implementations with
native keywords. 177 is already a compatible subset of all of them, so
there is no problem here.

The main problems we haven't yet resolved, as far as I can tell, are:

- 177 needs to use RnRS-portable read syntax, so we can't use keyword
objects. That means we need to use either symbols or strings to indicate
keyword arguments. Symbols would be the natural way to indicate hygienic
keywords, so it'd be nice to use something else for global keywords.

We could use strings, but that's very un-Lispy.

We could use quoted symbols: (keyword-call foo 1 2 ('c 3 'd 4))

Or we can use bare symbols: (keyword-call foo 1 2 (c 3 d 4)) and agree
that they are global keywords. In another future syntax, bare symbols
can indicate hygienic keywords instead. That may be slightly confusing,
but it may be the best compromise for the time being.

- The (a b &key c d) vs (a b (c d)) distinction. Affects whether or not
we can write the portable implementation using `syntax-rules`.

- The names of `keyword-lambda` and `keyword-call`; in time, we'll
settle on some decent names one way or another.

> Also, if some procedural macro system like `syntax-case' becomes more
> widespread (say because of inclusion in R7RS-large), we may want to
> revisit SRFI 177 because it would allow more syntactic freedom when
> specifying the interface.

The troubles with this SRFI may be a good argument for why there should
be a standard lower-level macro system lke syntax-case :)

> (2) Use of SRFI 177 in other SRFIs. As SRFI 177 won't probably be the
> last word about procedures with keywords, I wouldn't want to see other
> SRFIs (especially those intended to be included in R7RS-large)
> dependent on SRFI 177.

177 is explicitly designed so that other libraries' *interfaces* never
depend on it. It's only a dependency for the library *implementations*.
If a better syntax for keywords is found later, then the implementations
can gradually be converted to use that instead, while their interfaces
stay intact. 177 is meant to be an implementation detail, and to
co-exist and interoperate with all present and future keyword systems;
not to replace them.

If SRFIs are specified using keyword arguments, the main issue will be
whether those arguments are hygienic identifiers or unhygienic global
keywords. That's an issue that 177 cannot solve one way or another,
since 177 is (by design) at the mercy of what other keyword systems do.

> So far all libraries included in R7RS-large
> have gotten along without keyword arguments, so I don't think that we
> need and should invent APIs that are based on keyword arguments. This
> is different to Python where keyword arguments are used all over (but
> Python and its argument handling is slow, anyway).

The problem is that keyword arguments serve a real need; in their
absence people use alists or plists, which are *guaranteed* to be
unhygienic, non-type-checkable and non-optimizeable. With any keyword
system at all, a Scheme implementation has the possibility to do better
than the current situation.

> (3) Some Scheme implementations are slow and cannot (or don't want to)
> compete with C. For those, slower procedure call protocols may not
> make much of a difference. On the other hand, we have implementations
> like Chez. One reason why this implementation is so fast is because no
> compromises are made when not necessary. Chez has `case-lambda' for
> optional argument dispatch, but this can be made fast because by
> giving not well-known procedures several entry points (one for zero,
> one for one, one for two, etc. arguments) so that there is *no*
> dispatch argument. I fail to see how this can work with arbitrary
> keyword arguments.

It can't work with arbitrary keywords (i.e. allow-other-keys). The
Common Lisp implementations that optimize keyword calls, optimize only
the cases where all the keywords at the call site are known at compile
time. This is what people do 95% of the time in real code; seems good
enough to me. The Kawa/Racket semantics mostly allow the same set of
optimizations, but make them simpler to implement.