Hello,

First, I want to note that this "rant" is not against you Lassi, or
anyone. I only don't want my favourite language to be cluttered with
yet-another-concept that is not required or not helpful.

Again, I think my point of view is somewhat moot, so far. And I mainly
asking questions to understand whether this choice is solid or not.

Le dim. 3 nov. 2019 à 21:26, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> 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.
>

I don't know about the optimization strategies of rest arguments.
lambda/kw and call/kw would appear as regular lambda to the optimizer
in implementation that do not support keyword arguments so the
optimization strategy would be the same as the other arguments (if
any).

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

Maybe it is just purism ("oh no do not touch my precious lambda").
John cleared some of my fears when he wrote that existing calls to the
procedure will not require call/kw until they need to pass keywords.
That is good.

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

Yes, that can be made transparent in existing code using case-lambda.

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

Also, how far into keyword arguments we want to go.

Responding to another thread: Yes errors, will be made, as long as
(optional) static typing is not a thing in Scheme, less errors will be
caught at compile time. In real world, one does not ship code without
tests (same argument as static typing vs. dynamic typing). I don't
think that "first time run will error in silence" is a great point for
keyword arguments.

I hope we can balance the need for grown up frameworks and
applications in Scheme. Along, the ease of learning and implementing
Scheme.

I also agree, that the need is certain to have a keyword arguments
facility and that having to re-invent the wheel every time is not
good.

--
Amirouche ~ https://hyper.dev