> - Keywords being global symbols vs hygienic identifiers.
>
> I will believe in the need for hygienic keywords when someone demonstrates
> a non-hypothetical use for them.

The idea seems technically sound, but I'm also a bit skeptical that
well-working social conventions can be established among library writers
who do not communicate with each other.

Languages like Python, Ruby and Java are better than Scheme at
programming-in-the-large because as systems grow larger, social factors
start to dominate technical ones. The typical Lisper doesn't like to
admit it. I don't like to admit it. But it's true.

As we get out of core abstractions like closures and continuations, and
towards complexity-management tools like module systems, keyword
arguments, package management, documentation and tooling, I think we
should shift focus from mathematical purity to whatever supports
efficient social customs.

That being said, I don't want to block 177 from interoperating with any
hygienic keyword system. Fortunately it doesn't have to.

>> - 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.
>
> I propose this: if you really must have hygienic keywords, then in systems
> without keywords, a symbol beginning with ":" is treated as global.

Hmm. Could this be the best of all worlds?

(keyword-call 1 2 3 :foo 4 :bar 5 :baz 6)

This forbids a syntax-rules based implementation. But anyway, the macro
would scan the list until it finds either:

- A keyword object (in a Scheme that has such objects).
- A symbol whose name starts with `:`.
- A symbol whose name ends with `:`.

 From that point on, it would parse keyword-value pairs.

The natural complement for that keyword-call syntax would be John's
proposed (keyword-lambda (a b c &key foo bar baz) ...).

Opinions?

> If Marc's Chibi library can be made to cover Chicken, Gauche, and MIT
> (which will need patches for each one), I'd say that making syntax-case a
> standard is feasible.

Sounds great. I'm not qualified to judge syntax-case vs ER.

> I don't understand that. If a portable R7RS-large library wants to expose
> procedures that have keywords (and I'd like that), then it has to use
> either SRFI 177 conventions or some other conventions.

I mean the library writer and the library user can use different keyword
systems as long as those systems are compatible. For example I've called
Gambit's native procedures that take keyword arguments using SRFI 177
keyword-call; it worked fine.

This also implies that either the user or the library writer can switch
to a different keyword implementation at any time, independently of each
other, as long as those implementations are compatible.

177 is lowest-common-denominator so that it's compatible with anything
else, and so that it can be replaced with anything else. If it's not as
compatible it will fail; you just inadvertently presented a better
explanation of such failure than I did :)

> +1.  I have carefully avoided the need for them in R7RS-large so far, but
> SRFIs and pre-SRFIs are now starting to appear that simply have too many
> options to be handled as standard Scheme arguments.

That's generally a good indication that a solution is called for.

Another good case: go to the Common Lisp spec and imagine what some of
the built-in procedures would look like if you take out the keyword
arguments.