> How do you call `bar' in Common Lisp's/Gauche's model so that `x' and
> `y' do not receive any values but `foo' receives the value `3'?
>
> How would you handle a procedure that can arbitrarily many positional
> arguments and keyword arguments?
>
> With Kawa's model this is easily doable; with CL's/Gauche's model I
> don't see how.

IIRC there is no way to do that in the CL model. Another reason to
prefer all-#f default values for optional arguments.

The CL model prioritizes simplicity (of one kind) - it re-uses the rest
argument, which presumably existed years or even decades before keyword
arguments, to implement kwargs.

As discussed earlier, IMHO the CL semantics are already too nuanced for
reasonable real world scenarios. While implementing kwargs as a whole
new type of argument is more orthogonal, it complicates the language
even more than the CL style.

This is just my opinion, but I am strongly in favor of having a total
complexity budget for a language. That means each feature should justify
its complexity (which is also a good reason to be skeptical of having
kwargs at all).

Kwargs are solving a real problem as evidenced by the fact that people
are continually implementing their own ad hoc versions of them (or
thinking about doing so, as with several current SRFIs). But so far,
those can all be covered with the most trivial version of kwargs. It may
be that more features are needed (in particular, allow-other-keys) but
the examples demonstrating their necessity are fewer and not as clear.

The fancier kwargs are getting to be like method combination, multiple
inheritance and the meta-object protocol in CLOS - every part is
reasonable and logically specified in isolation, but when considering
the entire system one starts to doubt whether this is really the
simplest and soundest way to solve any practical problem.

> The optimization possibilities Per mentioned don't work with CL's model,
> which just looks like an ordinary plist argument in disguise.
> Marc

Can't (define/kw (foo a b #!key c d) ...) store information about its
argument list and the compiler check calls with read-time keywords at
the "right" positions? Is there a reason it can't optimize (foo 1 2 :d
4) if :d is read as a self-evaluating keyword object?