Thanks for your thoughts.

> 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.

I don't see it as argument from popularity; many of us have extensive
first-hand experience using keyword arguments (as well as their
alternatives: records, alists/plists and optional positional args).

> 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.

It's true that a long arglist is often a sign that one should make a
state object or a little DSL instead of one procedure. But the DSL thing
can also be overdone.

> 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.

Doesn't let-keywords do the same thing as lambda/kw, but less integrated
into the language with no opportunity for the implementation to
static-check and optimize it? I.e. you have to have a rest argument, and
then manually give that rest argument to let-keywords. IMHO it's just
more verbose, offers less opportunity for conventions to develop, and
has more room for error.

> 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.

It's not necessary to think about that. An ordinary lambda can be
replaced with lambda/kw when the time comes to add keyword arguments. If
you used optional positional arguments or an alist/plist rest argument,
you would still have to change the lambda-list, so it's not more work.

> 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.

I haven't heard anybody (outside of the Smalltalk language) advocating
that all arguments be named. Only optional arguments for procedures that
take many of them.