Am So., 3. Nov. 2019 um 11:11 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > It has been argued that "procedures" taking keyword arguments shall be
> > first-class procedures (so they cannot be implemented as macros, which
> > I would have preferred).
>
> My argument for that is just compatibility and uniformity. For example,
> if an RnRS procedure is extended with keyword arguments, that can't be
> done in a compatible way if the keyword procedure cannot act like a
> normal procedure in every way.

In R6RS, it can be done with identifier syntax.

As soon as we have syntax-case (or identifier syntax for
er-macro-transformers) in R7RS, it can also be done there. (And the
"Option 2" syntax already needs more than is in syntax-rules.)

>
> > First-class procedures with keyword arguments without any way to
> > forward unknown keyword arguments lose much of their power, though.
> > Thus, I think that if we want first-class procedures with keyword
> > arguments, we also need some mechanism to forward unknown keyword
> > arguments.
>
> I agree; it would be great to standardize that mechanism!
>
> 177 cannot can only have things that all implementations already supprt.
> But nothing stops us from writing SRFI 178 with a lambda/kw that
> supports allow-other-keys :) If it's a compatible superset of SRFI 177
> functionality, then users can import whichever SRFI they like. It's also
> possible to define another macro like `lambda/kw*`. But maybe it's best
> to extend lambda/kw. In either case, we should study how Gauche does it,
> since it has the most comprehensive allow-other-keys handling (it can
> separate recognized keyword args from unrecognized ones, as Shiro
> explained).

Maybe you could explain to me why it is so important that the
implementation of SRFI 177 builds upon the native keyword argument
system whenever one is present. This way we will end up only with the
least common denominator. But for what purpose?

What has to be done (and is being done:)) is to look at the various
native systems to get the best ideas. Then all it has to be made sure
that it isn't too hard to implement SRFI 177 on the most relevant
Scheme systems.

-- Marc