>> Do you mean that e.g. `open-output-file` as an identifier would evaluate
>> to a genuine lambda, whereas `(open-output-file ...)` would be a macro
>> that expands to the keyword argument checking and finally a fast call to
>> a lambda?
>
> Yes, this is possible and all that would be needed if we do not treat
> keyword arguments as first class objects (that can be forwarded).

It's worth thinking about this from a reflection standpoint too. Though
Scheme is designed with a focus on compilation, and reflection doesn't
need to be standardized in RnRS, is very useful in several implementations.

It should be possible to get the full argument list of a keyword
procedure if an implementation wants to provide that (for code
completion, etc.) If the identifier-syntax evaluates to a first-class
procedure, maybe the procedure object can have some
implementation-defined metadata tagged onto it. But then you can't call
that object with the keywords. Well, there could still be a separate
call-kw-object macro. Here the semantics start to get more complicated
when we deviate from standard lambdas; that's why my intuition suggested
staying with them. But all of this is still possible to handle in principle.

> R7RS-small uses the terms "expression type" and "syntax". What would
> "special primitive operator" add?

If "syntax" includes both macros and special operators, then "syntax" is
fine. I was worried that term would only mean macros :)

> The current version of SRFI 177 has a portable sample implementation
> (possibly depending on some low-level macro system), so native keyword
> arguments do not have to present. Thus I don't see why, for the
> purpose of SRFI 177, we have to be able to build upon them when they
> are present.

To take advantage of the work that 10 Scheme implementors have already
put into Scheme. If we have two incompatible keyword systems, that's
unfortunately the kind of thing that outsiders make jokes about :(

It's moderately bad that 177 already has different _syntax_ compared to
the implementation-native ones. We can alleviate that by making the 177
syntax look as similar to the existing ones as possible, which is why
"option 2" in the other thread was so popular.

But if we introduce incompatible _semantics_, so that the portable and
native keyword systems cannot talk to each other, I would have a hard
time explaining to programmers outside Scheme why that is a good idea.

I think the starting point should be that if e.g. Gauche implements
R7RS-large, then Gauche's native keyword arguments used in its built-in
procedures are instantly compatible with R7RS-large keyword arguments.
This leverages the existing work of all implementors who are using
keywords so far, and is less confusing to new Scheme programmers.

> I do not argue against this, not at all. :) But R7RS-small and R6RS
> compatibility do not demand that we have to compatible (what does it
> mean, by the way) with ad-hoc native keyword systems.

IMHO ad hoc is not a fitting expression for them; they've been in Lisp
since the eighties and have been in extremely wide use in applications
and libraries of all kinds.

To me, compatibility means that procedures defined using keyword-lambda
syntax A can be called using keyword-call syntax B, and vice versa. 177
currently keeps this promise for all known Scheme implementations.

> May I propose, before finalization of SRFI 177, to spec a, say, SRFI
> 178 first. SRFI 178 shall be a proposal for keyword arguments in a
> future R7RS-large version that has more freedom.

That may be a good idea. We should ask Arthur about the timeline for 177
finalization. I don't mind waiting some more to ensure we do a good job.

> I would like to see a clear upgrade path from SRFI 177 to such a SRFI
> 178 so that SRFIs that initially build upon SRFI 177 work with SRFI
> 178 as well and in the most natural way.

Agreed!