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.