Am So., 3. Nov. 2019 um 13:41 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >>> 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)

I think I am bit lost. What has it to do with the (orthogonal)
question whether we also want hygienic keywords?

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.

> 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 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.

>
> 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.

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.

>
> >> 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).