Quick vote about portable keyword argument syntax Lassi Kortela (01 Nov 2019 19:44 UTC)
Re: Quick vote about portable keyword argument syntax Marc Feeley (01 Nov 2019 20:12 UTC)
The name of "keyword-call" Lassi Kortela (01 Nov 2019 20:45 UTC)
Re: The name of "keyword-call" Lassi Kortela (01 Nov 2019 20:51 UTC)
Re: The name of "keyword-call" John Cowan (01 Nov 2019 20:54 UTC)
Re: The name of "keyword-call" Lassi Kortela (01 Nov 2019 20:59 UTC)
Re: The name of "keyword-call" John Cowan (01 Nov 2019 21:30 UTC)
lambda* Lassi Kortela (01 Nov 2019 21:47 UTC)
Re: lambda* John Cowan (01 Nov 2019 21:48 UTC)
Re: lambda* Lassi Kortela (01 Nov 2019 21:59 UTC)
curry/partial Lassi Kortela (01 Nov 2019 22:18 UTC)
Re: curry/partial John Cowan (01 Nov 2019 22:47 UTC)
Re: The name of "keyword-call" Marc Nieper-Wißkirchen (02 Nov 2019 16:23 UTC)
Re: The name of "keyword-call" Lassi Kortela (02 Nov 2019 23:16 UTC)
Re: The name of "keyword-call" hga@xxxxxx (01 Nov 2019 21:34 UTC)
Re: Quick vote about portable keyword argument syntax Per Bothner (01 Nov 2019 20:57 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (01 Nov 2019 21:06 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (02 Nov 2019 16:22 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (02 Nov 2019 16:42 UTC)
Re: Quick vote about portable keyword argument syntax John Cowan (02 Nov 2019 16:48 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (02 Nov 2019 16:57 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (02 Nov 2019 23:28 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (02 Nov 2019 23:47 UTC)
Re: Quick vote about portable keyword argument syntax John Cowan (03 Nov 2019 02:36 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 08:49 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 09:56 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 10:27 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 11:17 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 11:31 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 12:41 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 15:20 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 15:40 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 15:50 UTC)
Re: Quick vote about portable keyword argument syntax John Cowan (03 Nov 2019 19:39 UTC)

Re: Quick vote about portable keyword argument syntax Lassi Kortela 03 Nov 2019 12:41 UTC

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