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