Advanced file port operations: please review. John Cowan (01 Nov 2019 23:01 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 00:14 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 02:19 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 15:43 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 18:15 UTC)
SRFI 177 as a dependency for keywords in other places Lassi Kortela (02 Nov 2019 23:00 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (03 Nov 2019 08:33 UTC)
Keyword arguments in R7RS-large and SRFIs Lassi Kortela (03 Nov 2019 09:16 UTC)
Re: Keyword arguments in R7RS-large and SRFIs Amirouche Boubekki (03 Nov 2019 14:28 UTC)
Re: Keyword arguments in R7RS-large and SRFIs Lassi Kortela (03 Nov 2019 15:53 UTC)
Re: Keyword arguments in R7RS-large and SRFIs John Cowan (03 Nov 2019 19:30 UTC)
How and Why keyword arguments are useful or harmful? Amirouche Boubekki (03 Nov 2019 20:11 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (03 Nov 2019 20:14 UTC)
Re: How and Why keyword arguments are useful or harmful? Lassi Kortela (03 Nov 2019 20:26 UTC)
Re: How and Why keyword arguments are useful or harmful? Lassi Kortela (03 Nov 2019 20:30 UTC)
R7RS-large keyowrds Lassi Kortela (03 Nov 2019 22:18 UTC)
Re: R7RS-large keyowrds John Cowan (03 Nov 2019 22:29 UTC)
Re: R7RS-large keyowrds Lassi Kortela (03 Nov 2019 22:34 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 10:49 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 17:49 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:08 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 18:10 UTC)
Re: R7RS-large keyowrds Marc Feeley (06 Nov 2019 18:16 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:17 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 20:23 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:16 UTC)
Re: R7RS-large keyowrds Marc Feeley (06 Nov 2019 17:59 UTC)
Re: R7RS-large keyowrds Lassi Kortela (09 Nov 2019 12:29 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (09 Nov 2019 12:53 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 03:31 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 04:10 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 03:43 UTC)
Re: How and Why keyword arguments are useful or harmful? Marc Nieper-Wißkirchen (06 Nov 2019 13:25 UTC)
When is a feature necessary Lassi Kortela (03 Nov 2019 22:06 UTC)
Re: When is a feature necessary Lassi Kortela (03 Nov 2019 22:13 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (06 Nov 2019 10:21 UTC)
Re: SRFI 177 as a dependency for keywords in other places Lassi Kortela (09 Nov 2019 11:55 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:40 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:13 UTC)
Re: Advanced file port operations: please review. Shiro Kawai (02 Nov 2019 10:15 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 14:36 UTC)
Port settings Lassi Kortela (02 Nov 2019 10:28 UTC)
Re: Port settings John Cowan (02 Nov 2019 14:00 UTC)
Re: Port settings Lassi Kortela (02 Nov 2019 14:13 UTC)

Re: Keyword arguments in R7RS-large and SRFIs Amirouche Boubekki 03 Nov 2019 14:27 UTC

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