>>> 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.
>
> Options 1, 3, and 4 don't use keywords-as-strings or quoted symbols.

The thing is, 177 needs to support unhygienic global keywords in any
case since that is what everyone Scheme and Lisp is currently using.
There has to be some syntax for them. The options are:

- Bare symbols like foo are unhygienic; not sure what to use for
hygienic ones.

- Colon symbols like :foo or foo: are unhygienic; symbols without colons
are hygienic.

- Quoted symbols like 'foo are unhygienic; bare identifiers are hygienic
(or vice versa).

- Strings like "foo" are unhygienic and identifiers are hygienic (or
vice versa).

- Some differentiator like (unhygienic foo) or (hygienic foo)

None of these are ideal, and all of these are difficult to pick from the
call/kw lambda list unless we use one here-come-the-keyword-arguments
marker like (call/kw 1 2 : foo 3 bar 4) or (call/kw 1 2 (foo 3 bar 4)).

> But non-conformance of some implementations shouldn't dictate that
> things become non-uniform for conformant implementations.

I think most successful standards uphold principles but also know when
to yield to implementations. Some famous internet standards process (the
RFCs?) has a general rule that they don't standardize anything until it
has been in wide use for some time. Everything else is just called a draft.

I can't think of a single successful standard that goes completely
contrary to established practice. Even Python 2 -> Python 3 was a very
difficult transition. Standardizing tried-and-true things is generally a
very fruitful endeavor.

> I am a mathematician. Beauty matters as much as practicalness. :)

Scheme is arguable the most beautiful language, so I see your point.
Keyword args are a difficult topic because the whole idea is a bit ugly
to begin with, especially from a mathematical perspective that each
function has a clean, well-defined set of arguments. Keyword args are a
bit like JSON, that "just give up on elegance and accept that our
creations will keep growing without bound" mindset.

>> 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.
>
> Do you think so?

I'm not sure; I haven't thought about it in detail. I'm hoping other
people will have a better perspective on that :D

> And even if, R7RS-large itself would still take much longer until completion.

We need to get more and more of R7RS-large into wider use even in the
work-in-progress stage. If it takes 10 years and has a lot of untried
new design, it risks becoming a Titanic of standards (I'm sure John is
painfully aware of this risk).