> As soon as other SRFIs (especially SRFIs for inclusion into
> R7RS-large) begin to use SRFI 177 in their external API, things will
> be set into stone.
>
> Thus, let's be careful from the beginning.

I still don't understand why the lambda/kw and call/kw syntax needs to
be set in stone. As far as I can tell, it does not have to be.

A keyword procedure is often defined in a different place than where it
is called. That means the definition and the call can use completely
different syntax, as long as those syntaxes have compatible semantics.

The current 177 call/kw can call Gambit/Gauche/Kawa built-in procedures
that have been defined using the native keyword syntax of those Schemes.
It works just fine. This is what I want to preserve :)

> No. :)
>
> While you can certainly define macros that destroy this uniformity,
> all special forms (including macros) in R7RS(-large) retain Scheme's
> uniformity.
>
> For example, "cond" and "case" match "else" and "=>" hygienically and
> do look at how "else" or "=>" are spelled.
>
> Let's keep this uniformity with SRFI 177.

That's true. However, we probably can't keep that aspect with 177
without using something IMHO worse like keywords-as-strings or quoted
symbols.

Again, my defense is that 177 does not need to be the only keyword
syntax, and doesn't need to be the syntax that goes into R7RS-large.

> R7RS-large builds upon R7RS.
>
> Of course, one could think of a reader flag "#!keywords" that changes
> how ":foo" and/or "foo:" are read. In this case, however, they would
> be no identifiers and my argument from above doesn't apply.
>
> In the absence of such a flag, however, ":foo" and "foo:" are
> identifiers in portable (R7RS-portable) code.

The trouble is that implementations don't always conform to the portable
syntax in the obvious manner. As a practical example, the #u8 vs #vu8
vector syntax causes trouble. If you write libraries and you care mainly
about the widest compatibility, with the standards being only a means to
that end, it's no problem to stick to a least-common-denominator subset
of all desired syntaxes in your code. It's usually a small sacrifice to
make if you can achieve more portable code.

Again, R7RS-large is a big enough effort that maybe it should "bless" a
particular keyword syntax. I'll leave that decision to others.

> The best way out would be to standardize something like "#!keywords"
> first. When this flag is not enabled in a source file, Schemes should
> offer an R7RS conformant mode if they claim R7RS conformity.

As a library writer, I would just use whatever mode works :)

It might be worth writing a "keyword syntax truce" SRFI that makes all
implementations support the same read syntax for keywords. But it would
take years until most implementations support that SRFI.

> Let's first try to get the semantics (and syntax) of SRFI 177 right.
> And in a way such that SRFI 177 allows for native implementations by
> various Schemes.

For better or worse, the semantics have been dictacted by Common Lisp,
DSSSL, and 10 Scheme implementations long before work started on
R7RS-large and 177. Implementations like Gambit and Gauche that use
kwargs a lot in their built-in procedures will have a hard time if
incompatible semantics are introduced in a future Scheme standard, not
to mention the culture shock of programmers coming from any other
language :)

177 has never introduced any new semantics, and I don't think it should.
What it can do, is leave the door open for future standards to have
semantics that are a compatible superset of what it can do.

> If the reference implementation can only implement 98% of the
> semantics (because 2% have to implemented non-portably), it's fine as
> long as it is not hard for each Scheme to copy with the remaining 2%
> individually.

I agree that this is fine. A fully portable implementation is not
possible anyway if we want to be compatible with existing native
keywords. The current R5RS syntax-rules thing is just a fallback so
every Scheme at least has something.

> But good design also includes the uniformity I mentioned above. And
> here, it would become non-uniform and non intuitive, especially in
> Scheme dialects where the natural keyword syntax is "#:key" (which is
> probably better than ":key" or "key:" because it does not clash with
> the R7RS identifier syntax).

That applies to code written specifically for those Schemes. But I hope
we'll have an increasing amount of portable code that is not written
specifically for any particular Scheme implementation. In that
situation, one has to watch out for things like the :key or key:
differences anyway.

I regret that 177 probably has to be done in such a way that
vertical-bars don't protect you from the ambiguity, but the alternatives
are worse.