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

How and Why keyword arguments are useful or harmful? Amirouche Boubekki 03 Nov 2019 20:11 UTC

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.