>> 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)
>
> I think I am bit lost. What has it to do with the (orthogonal)
> question whether we also want hygienic keywords?

It only matters if we want 177 (supporting only unhygienic keywords) to
have a syntax that will be a subset of a future syntax supporting both
hygienic and unhygienic keywords. In that case, the future syntax would
be a drop-in replacement for 177: just replace (import (srfi 177)) with
some other import, no need to edit any of the code that uses call/kw.

If we don't care about switching to an imcompatible syntax later, then
it doesn't indeed matter.

In both cases, the truly important is that the _semantics_ are
compatible (i.e. if hygienic keywords are introduced later, then the
macros implementing SRFI 177 in that Scheme can simply expand to
whatever syntax is needed to work with the new system). An incompatible
syntax is at worst a minor inconvenience, whereas incompatible semantics
would risk splintering the Scheme community (similar to the R6RS vs R7RS
split).

> Options 1, 3, and 4 support unhygienic global keywords out of the box.
> Contrary to Option 2, they do not cause call/kw to have non-uniform
> semantics with respect to all other special forms in Scheme.

I don't recommend that R7RS-large keep the :foo and foo: identifiers
hack from the 177 macros. If you are allowed to add keyword objects to
the base language, you'll get a cleaner result.

The :foo and foo: hack would then only be needed for R6RS, R7RS-small,
and individual implementations. In the future, if we can standardize the
read syntax of keyword objects, we can also issue a simplified version
of 177 that doesn't have the hack. I think this would be the best end
result.

We just need a hack for the evolutionary stage during the next few years.

>> 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 don't see what this has to do with my argument because it would mean
> to standardize something which is a violation of the standard.

My argument is that all standards are ultimately "de facto" standards.
If a formal standard deviates too much from what people want in
practice, then people will subvert that standard or switch to another
one. The art in writing standards is like herding cats: people want to
each do their own thing, and you have to subtly encourage them to go in
your direction instead. If you try to force them to go your way, they
will often resist a lot; instead, we have to persuade.

Is it a violation of R7RS-small if a macro parses its own identifiers
and makes decisions to expand to different code based on them? Doesn't a
macro have the right to scan for a colon in an identifier and handle it
how it wants?

>> 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.
>
> I can live with this (although I wouldn't use keywords for a newly
> created Scheme API as said before).
>
> The ugly thing would be to make the "values" hack necessary because
> not all identifiers are treated on an equal footing.
>
> While the syntax of "Option 2" may look a bit more convenient that
> your original syntax of "Option 1", the advantage is not that big to
> create the wart I have spoken of. On top of that, "Option 1" has the
> (slight) advantage that is has a portable R7RS-small implementation.

If you can introduce a standard keyword object syntax in R7RS-large,
then I recommend leaving the identifiers hack out of it (unless John has
a good rationale to the contrary). The hack can stay only in 177 macros.

In that case, R7RS-large users who need portable code can still import
177 manually - it just won't be part of the standard. Since 177 macros
(the proposed option 2) work equally well with keyword objects as :foo
or foo: symbols, any call/kw expression using R7RS-large keyword objects
would also be a valid 177 call/kw expression.

As far as I can tell, everybody wins that way :)