Le dim. 3 nov. 2019 à 10:16, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> > 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.
>
> I'll leave the R7RS-large decision to others.
>
> But a related concern is that some SRFI authors may want to use keyword
> arguments. If you want to include some functionality in R7RS-large and
> the SRFI about that topic happens to use keyword args, how will the
> issue be resolved - change the API from the SRFI or design a new API?
>
> We could have an informal agreement not to use keyword args in SRFIs
> that might go into R7RS-large. My personal opinion is that that would be
> a bad call, because for many complex tasks, all the alternatives to
> keyword args are a poor emulation of them:
>
> * optional positional arguments (same as kwargs with no names)
> * alist or plist argument (like kwargs with no static checking or
> optimization)
> * record type (like kwargs, but need to define a new record type just
> for one procedure)
>
> SRFI 167 (just being finalized) has good examples:
>
> (make-engine open close in-transaction ref set delete range-remove range
> prefix-range hook-on-transaction-begin hook-on-transaction-commit pack
> unpack)

This is a write-once use-many expression, so it is not a good
candidate for keywords.

>
> (engine-in-transaction engine okvs proc [failure [success [make-state
> [config]]]])
>
> (engine-range engine okvs start-key start-include? end-key end-include?
> [config])

In those, only config is really a candidate to keyword arguments the
others have well-known default values:

  failure -> raise
  success -> values
  make-state -> make-default-state

That is it is easy to customize.

> IMHO all of these would be easier to understand (and to make
> implementation-defined extensions) with keyword args.

--
Amirouche ~ https://hyper.dev