Am So., 3. Nov. 2019 um 22:32 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Nov 3, 2019 at 3:33 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> I strongly suggest not to do this for any API that is for inclusion
>> into R7RS-large.
>
>
> What do you suggest for the proposed file-open for SRFI 170, with its required argument "pathname" and its six other arguments?  My original design used a p-list, but that loses performance on Schemes with native keywords already.  Other examples are arising soon.

I have taken a look at your
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FilesAdvancedCowan.md.
I hope this is what you have had in mind.

The "settings" argument is used for procedures opening files, which
are non-trivial themselves. Thus, I don't think the loss of
performance when plists are used will be noticeable in any way;
furthermore, an optimizing compiler should be able to compile it
efficiently when the called procedure is known at the call site.

As many procedures share the same settings argument, a better
solution, though, seems to be to define an opaque "settings" type.
Values of the settings type are created by a special form provided by
the advanced files API. An example:

(call-with-input-file pathname (file-settings exclusive (encoding 'utf-8)) proc)

The "file-settings" keyword can be implemented as a syntax-rules or as
an er-macro-transformer/syntax-case macro.

Under the hood, the implementation can use plists or record types or
some other fast native device to implement the opaque "settings" type.
The implementation in schemes with native keyword arguments can even
macro-overload "call-with-input-file" so that the above is expanded
into "(call-with-input-file pathname proc exclusive: #t encoding:
'utf-8)".

This approach has two advantages: It can be made type-safe (the
implementation can complain at compile-time when an unknown or
misspelled setting is used), and port settings can be forwarded
because they are general Scheme types.

Besides, the call above looks much nicer than "(call/kw
call-with-input-file pathname proc exclusive: #t encoding: 'utf8))"
(or any other of the discussed alternative syntaxes for SRFI 177)
because of the necessity of "call/kw".

>
>>
>> (I'm not arguing against using SRFI 177 to implement an API. But new
>> APIs definitely do not need keywords, even not to be pretty.)
>
>
> R7RS-large is not about what is *needed*, nor is R7RS-small.  All we *need* are lambdas, or if we must have lists, all we *need* for them is pair?, cons, car, cdr, set-car!, and set-cdr!.  Remember the goals of R7RS-large from our charter: "a language that embodies the essential character of Scheme, that is large enough to address the practical needs of mainstream software development, and that can be extended and integrated with other systems."

I was referring to the idea that the main advantage of keyword
arguments is that parameters can be added to API calls in a
backward-compatible way. Under this assumption, one should think twice
whether newly designed APIs shall make use of keyword arguments.

So far, R7RS-large already includes a huge number of procedures. None
of these make use of keyword arguments but the solve the perceived
problem in other, not less elegant, ways. Confer my example of
"set-copy" and "set-filter" in SRFI 113, for example. If R7RS-large
had had keyword arguments from the start, only "set-copy" would have
been needed.

If keyword arguments suddenly go into widespread use in the middle of
the standardization process of R7RS-large, we end up with a not very
uniform overall API of R7RS-large.

Scheme is not Python (where keyword arguments have been baked in from
the start) and has nevertheless been an elegant language and has been
able to support elegant APIs without any keyword arguments. It is not
so clear to me why this isn't true anymore.

Marc