Am Sa., 9. Nov. 2019 um 12:55 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> Thanks again for the thoughtful contrarian arguments Marc.

Thanks; the ability to use keyword arguments (in a portable way) would
deeply change how we program in Scheme and design our procedures. At
the moment, we may have use cases like some procedures in SRFI 170 in
mind, but when keyword arguments are generally available, people will
also start to use them in case where they have used positional or
optional arguments previously (e.g. in procedures like R7RS-small's
"member"; maybe even in procedures with many arguments like SRFI 1's
"unfold").

Thus endorsing a SRFI like SRFI 177 as a part of R7RS-large, would
cause the core language (its canonical idioms) to change.

You have yet failed to convince me that this fundamental change is
necessarily a good one and widely accepted; until then I will remain a
critic. ;)

Compare this with, say, your SRFI 169. Some will like it, some won't,
it may be included in R7RS-large or it may not, it may even become
part of R8RS, whatever. But it won't change what I would call the core
of the language.

To give another example:

Python has built-in dictionaries, so they are used ubiquitary (even in
other core constructs like class dictionaries, etc.).

Now think of a language addition to Scheme that deeply integrates hash
tables into the language (by providing some syntactic sugar, by giving
hash tables read and write syntax, etc.). For sure, this would change
how Scheme would be used everyday (why use plists or alists when you
have simple and fast hash table syntax?).

I'm not saying that such an addition is necessarily bad, but it should
only come after giving it a lot of thought (and a lot of time to think
about) as it would be some fundamental change. Such a change should
probably happen in the core language (R?RS-small) and not in the
extension of the core language (R?RS-large).

>
> >> I was referring to the idea that the main advantage of keyword
> >> arguments is that parameters can be added to API calls in a
> >> backward-compatible way.
> >
> > I think the main advantage is readability.  You can just as well add
> > ordinary unnamed arguments at the end of an ordinary lambda-list, but at a
> > high cost in readability.
>
> To me the best thing is that it's easy for users. You can add arguments
> and move on to more other work without having these deliberations each time.

Most of one's programming time (when programming libraries) should go
into the design of the API and not into the actual programming work.
(A bit exaggerated, for sure, but you know what I mean.) A similar
thing is true when specifying an API.

Thus, having the ability of adding keyword arguments at the end of
argument lists without having to think too much, it not necessarily a
good thing.

I agree, though, that it makes sense if the language hints at some
preferred ways to solve this problem.

>
> The most hardcore Haskellers might prefer to make a composable DSL out
> of everything. I'd agree in many cases, but should we really make a new
> DSL for every library with a `find`- or `open`-style procedure?

Thanks for Scheme's macro system, the situation is much better than
with Haskell. In Scheme, you can spec a DSL for a DSL generator. :)

In some sense, the proposal I made in a reply to one of John's posts,
namely having an opaque settings type (and some syntax that allows one
to easily create such settings types) can be seen as some (very
limited) form of DSL that solves the "keyword argument" problem.

(One advantage of that solution

>
> Looking at prior art from Common Lisp and Emacs, the no-effort solution
> of keywords tends to be at least 80% as good as a tailor-made solution
> would be (look at some procedures with keyword/optional args and imagine
> replacing them with a record or DSL).

Scheme is neither Common Lisp, not Elisp.

The syntax may be the same but they are very different languages. (The
whole hygiene discussion we have had is a symptom of this; just moving
Common Lisp syntax to the Scheme world does not necessarily lead to
clear and uniform semantics.)

Marc