Email list hosting service & mailing list manager

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:13 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 02:19 UTC)
Re: Advanced file port operations: please review. Shiro Kawai (02 Nov 2019 10:14 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:12 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:14 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:32 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:27 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:29 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:48 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:12 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: How and Why keyword arguments are useful or harmful? Amirouche Boubekki 03 Nov 2019 20:14 UTC

Le dim. 3 nov. 2019 à 21:11, Amirouche Boubekki
<xxxxxx@gmail.com> a écrit :
>
> Thanks for the replies.
>
> Le dim. 3 nov. 2019 à 20:30, John Cowan <xxxxxx@ccil.org> a écrit :
> >
> >
> >
> > On Sun, Nov 3, 2019 at 9:28 AM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
> >
> >> > (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.
> >
> >
> > Per contra, I think it is an *excellent* candidate.  The arguments are all procedures with no hope of distinguishing them at run time.  If the programmer gets the order of the two hooks wrong, only testing against an actual database (hopefully not one with live data) will expose the error.  With keywords (or one of their alternatives), the programmer is forced to state their intentions explicitly.
>
> This is supposed to be tested in unit tests like at the moment:
>
>   https://github.com/scheme-requests-for-implementation/srfi-168/blob/f48581d0f56d66d036e9712ccbbff8cbba9ca23a/srfi/168/test.sld#L156-L178
>
> >
> >>
> >> > (engine-in-transaction engine okvs proc [failure [success [make-state
> >> > [config]]]])
> >
> >
> > This is another good candidate for keywords, although not as strong.  Here if you want to specify success handling, you must specify failure handling even if you don't care.  We simply guess in such APIs that special handling on failure is more probable than special handling on success, but what if we are wrong?  An unadorned "raise" may not in a given framework be the right thing.  I'm not carping about this because we have so many SRFIs that use this design, but it is suboptimal.
>
> Then the "framework" would provide a (make-default-failure . args) procedure.
>
> So far, I have not seen arguments that convince me that keyword
> arguments are a good thing. It seems a lot like "everybody does it,
> let's do it too". I have not seen a (good?) argument for it as of yet.
>
> My arguments against keyword arguments are:
>
> a) All around, the language is more difficult to master because there
> is one more concept.
>
> b) Unamed arguments are defacto standard in all languages, so there
> might be a good thing. The thing that unamed arguments do, is they
> allow to keep the code short, it avoids repetitions of well-known
> arguments e.g. car, cdr, map, fold... I argue that if there is more
> that 5 arguments (because humans can only remember 5 things at the
> same time (which used to be 7)) the function must be split.
>
> In that procedure:
>
> >> > (engine-in-transaction engine okvs proc [failure [success [make-state
> >> > [config]]]])
>
> One could move failure success and make-state to config. That would be
> keywords in disguise... Because I am in favor of let-keywords which is
> less demanding on the user than call/kw and lambda/kw.
>
> call/kw and lambda/kw is a new calling convention. This must not be
> implemented without a lot of thinking. Now any time the user wants to
> call a procedure they must think whether it takes or not keywords.
> This might be the case only in wanna-be portable code. If it is
> included in R7RS-large, it will be The Language.
>
> It raised to my attention that in SRFI-170 there is a procedure like
> the following:
>
>   (open-file path append truncate create exclusive permissions)
>
> And at the time the user read or write the code, one must count the
> exact position of each argument to know what they do. I think chez
> pass symbols instead of booleans that will help to remember and to
> read.
>
> Maybe another reason, I am not sure about keywords, is because they
> have the same "documentation" argument that static typed language use
> for static typing.

If that helps, I can pick some Scheme code that rely on keyword
arguments and explain how to make the code more clear without keyword
arguments.

Now, that I have written that I figured that I might also be against
the _use_ of case-lambda.

--
Amirouche ~ https://hyper.dev