Am Fr., 24. Apr. 2020 um 09:27 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

[...]

> As far as I can tell, it covers the most important use cases ("the 80%
> case").
>
> With 177 these can already be done, for example:
>
> ;; Gambit
> (open-process (call/kw list (path "ls" arguments '("/bin"))))
>
> ;; Gauche
> (call/kw uri-decode-string "hello+wörld" (cgi-decode #t encoding "utf-8"))

My point is that if `open-process' and `uri-decode-string' are native,
unportable procedures there is no need to call them in a portable way.
If, on the other hand, they are rewritten following some portable
specification (e.g. some procedure in SRFI 170), they don't have to be
implemented using some native, non-portable keyword system.

> Likewise, you can (define/kw ...) things that can be used seamlessly
> with the existing keyword syntax and function call semantics of those
> Schemes.
>
> I don't see how the focus of the SRFI could be any more practical than
> this. All you have to do to get all of this is to type an extra
> `call/kw` in a few places, and even that only concerns people who want
> to use the SRFI instead of the many other compatible keyword systems.
>
> The SRFI could be much better from purity standpoint, to be sure. I'll
> happily incorporate anything that doesn't detract from its practicality.

I don't want to say that this SRFI is useless. I would, however, like
to see that whatever simple "native keyword system" R7RS-large chooses
for other SRFIs is also covered by SRFI 177 so that the rest of
R7RS-large does not necessarily have to refer to SRFI 177. For
example, I would like to be able to write something simple like
`(make-hash-table (make-eq-comparator) 'initial-size 1000)' without
the need of any `call/kw'.