SRFI 177 has been advertised that it offers a portable way to extend
an API while retaining compatibility.

This is different to designing an API from scratch using keyword arguments.

I strongly suggest not to do this for any API that is for inclusion
into R7RS-large.

So far, 100% of what goes into R7RS-large gets along without keyword
arguments. Either positional optional arguments are used (e.g. by
"hash-table-update!" in SRFI 125) or distinct procedure names are used
(e.g. "set-filter" and "set-copy" in SRFI 133, which could have been
made into one procedure "set-copy" through a "#:filter" keyword
argument).

If we change the general design of APIs along the way, the resulting
R7RS-large standard may look more than we want like a Lisp ball of mud
than like a Scheme snowball.

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

Marc

Am So., 3. Nov. 2019 um 00:00 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > Adding open-file to SRFI 170 with keywords is a no-brainer, I think: we'll
> > say that 170 depends on 177, and rig the ballot so that a vote for 170 is a
> > vote for 177 as well.  I did this with 128 in the Red Edition; it's
> > appropriate whenever a SRFI's interface, as opposed to its implementation,
> > depends on another SRFI.
>
> Interesting.
>
> I wonder how SRFI 177 dependencies should be declared. I intended it to
> have just the macros. The macros implement keyword argument semantics
> that are basically independent of the API in the SRFI. But since the API
> surface is very small with only 2 macros, maybe it does no harm to have
> the SRFI itself as a dependency for some things.
>
> > What to do about the R[567]RS procedures is more difficult.  Because of
> > call/kw they aren't just drop-in replacements as I had originally intended.
> > I think the simplest thing is to make the fdes->port functions
> > keyword-based.
>
> SRFI 177 is deliberately designed so that keyword lambdas can be called
> like ordinary lambdas when no keywords are given to them.
>
> So for example a keyword lambda:
>
> (call-with-output-file string proc [settings-as-keyword-arguments])
>
> Can always be called as
>
> (call-with-output-file string proc)
>
> just like RnRS `call-with-output-file`.
>
> Only if you want to give some keywords, do you need to use `call/kw`:
>
> (call/kw call-with-output-file string proc :exclusive #t)
>
> Of course, if you know you only need to support a particular Scheme
> implementation and it has native keywords, you could leave out the call/kw.
>
> The advantage of full compatibility with native `lambda` really becomes
> apparent in scenarios like this RnRS interoperability thing.