Email list hosting service & mailing list manager

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:13 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:14 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:12 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:14 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:32 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:27 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:29 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:48 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:12 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: How and Why keyword arguments are useful or harmful? Amirouche Boubekki 04 Nov 2019 03:43 UTC

Le lun. 4 nov. 2019 à 00:52, John Cowan <xxxxxx@ccil.org> a écrit :
>
>
>
> On Sun, Nov 3, 2019 at 3:11 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
>
>> b) Unamed arguments are defacto standard in all languages, so there
>> might be a good thing.
>
>
> Well, Fortran and Lisp 1 had unnamed arguments because they were imitating mathematical notation.  Cobol, which is about the same age, has statements like "ADD a, b TO c ROUNDED, d, E ROUNDED, ON SIZE ERROR <some command>".   Cobol hasn't been influential on other languages (which are often invented by people with mathematical training), but it has been extremely persistent: it is one of three survivors from that era.
>

Thanks for this note.

>>
>> 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.
>
>
> I actually think (standardizer hat off) that 2 ordered arguments, left and right, are about all humans can handle.  Human language verbs can be infix like English, postfix like Latin, or prefix like Arabic (much rarer than the other two for whatever reasons), but they don't have long strings of noun phrases without an indication of what they are for.  Beyond two arguments, humans go to keywords (prepositions or case endings or both).  In British English you can say "Give it me" or "Give me it", and only the semantics differentiates, but American English, usually more literal-minded, will accept "Give me it" but insists on "Give it to me", and even British English won't tolerate "Give it George"; George in that case must be the gift.
>

It is maybe time to grow up :)

>>
>> 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.
>
>
> Not so.  They only think if they want to actually pass the keywords.  If they don't, it can be called like any other procedure.
>

Thanks for making that clear.

>>
>>   (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.
>
>
> It's not there yet, only proposed for addition.  Symbols help, but you still need to pass them all in the right order (hard to remember), at most omitting final ones.  Either that or it's a list of symbols, with no type-checking and run-time decoding.  R6RS erects a complex structure for textual-port-specific properties, using a record and then macros for the particular values.
>

Indeed, that is far from perfect.

>> 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 am thinking strongly of static typing *syntax* for R7RS-large, but leaving semantics up to particular programs, as in Python.

I did not want to ask directly. At think it will be wise, given how
_optional_ static typing has taken the world very quickly.

> By all means give us examples of alternatives to keywords.

They are already spread here and there in various comments. I will try
to write a comprehensive overview of keyword alternative and usage.

Here is how I do it in SRFI-167:

https://github.com/scheme-requests-for-implementation/srfi-167/blob/95f860e7bb516564963dda6ff2360c9773ae0cfe/srfi/memory.sld#L226-L265