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