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? Marc Nieper-Wißkirchen 06 Nov 2019 13:25 UTC

Am Mo., 4. Nov. 2019 um 00:52 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> 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.
>
>>
>> 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.

Funnily, in German the interpretation would be the other way round:
"Gib es Georg!" would mean to give it ("es", direct object) to George
("Georg", indirect object).

I don't know of a sensible sentence where more than two nouns without
case endings appear in a row. However, it is possible to put a lot of
infinitives of modal verbs in a row. E.g. "Ich werde es Georg geben
können müssen." (Literally: "I will must can give it to George.")
Nevertheless, the logic dictates the word order here, so it remains
parsable by the human brain.

>
>>
>> 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.
>
>>
>>   (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.
>
>> 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.

We could start with providing means to associate compile-time values
or properties to identifiers that can be used by macros.

I am thinking of something like this here provided by Chez Scheme:
https://cisco.github.io/ChezScheme/csug9.5/syntax.html#./syntax:h4

On top of that, one can use higher-level constructs and macros to
implement static typing syntax and even static type (if a library
author wants to provide this).

>
> By all means give us examples of alternatives to keywords.
>
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
> As you read this, I don't want you to feel sorry for me, because,
> I believe everyone will die someday.
>                --From a Nigerian-type scam spam
>