Advanced file port operations: please review. John Cowan (01 Nov 2019 23:01 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 00:14 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 02:19 UTC)
Re: Advanced file port operations: please review. Shiro Kawai (02 Nov 2019 10:15 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 14:36 UTC)
Port settings Lassi Kortela (02 Nov 2019 10:28 UTC)
Re: Port settings John Cowan (02 Nov 2019 14:00 UTC)
Re: Port settings Lassi Kortela (02 Nov 2019 14:13 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 15:43 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 18:15 UTC)
SRFI 177 as a dependency for keywords in other places Lassi Kortela (02 Nov 2019 23:00 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (03 Nov 2019 08:33 UTC)
Keyword arguments in R7RS-large and SRFIs Lassi Kortela (03 Nov 2019 09:16 UTC)
Re: Keyword arguments in R7RS-large and SRFIs Amirouche Boubekki (03 Nov 2019 14:28 UTC)
Re: Keyword arguments in R7RS-large and SRFIs Lassi Kortela (03 Nov 2019 15:53 UTC)
Re: Keyword arguments in R7RS-large and SRFIs John Cowan (03 Nov 2019 19:30 UTC)
How and Why keyword arguments are useful or harmful? Amirouche Boubekki (03 Nov 2019 20:11 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (03 Nov 2019 20:14 UTC)
Re: How and Why keyword arguments are useful or harmful? Lassi Kortela (03 Nov 2019 20:26 UTC)
Re: How and Why keyword arguments are useful or harmful? Lassi Kortela (03 Nov 2019 20:30 UTC)
R7RS-large keyowrds Lassi Kortela (03 Nov 2019 22:18 UTC)
Re: R7RS-large keyowrds John Cowan (03 Nov 2019 22:29 UTC)
Re: R7RS-large keyowrds Lassi Kortela (03 Nov 2019 22:34 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 10:49 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 17:49 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:08 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 18:10 UTC)
Re: R7RS-large keyowrds Marc Feeley (06 Nov 2019 18:16 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:17 UTC)
Re: R7RS-large keyowrds John Cowan (06 Nov 2019 20:23 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (06 Nov 2019 18:16 UTC)
Re: R7RS-large keyowrds Marc Feeley (06 Nov 2019 17:59 UTC)
Re: R7RS-large keyowrds Lassi Kortela (09 Nov 2019 12:29 UTC)
Re: R7RS-large keyowrds Marc Nieper-Wißkirchen (09 Nov 2019 12:53 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 03:31 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 04:10 UTC)
Re: How and Why keyword arguments are useful or harmful? Amirouche Boubekki (04 Nov 2019 03:43 UTC)
Re: How and Why keyword arguments are useful or harmful? Marc Nieper-Wißkirchen (06 Nov 2019 13:25 UTC)
When is a feature necessary Lassi Kortela (03 Nov 2019 22:06 UTC)
Re: When is a feature necessary Lassi Kortela (03 Nov 2019 22:13 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (06 Nov 2019 10:21 UTC)
Re: SRFI 177 as a dependency for keywords in other places Lassi Kortela (09 Nov 2019 11:55 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:40 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:13 UTC)

Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen 09 Nov 2019 13:40 UTC

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