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.
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.
By all means give us examples of alternatives to keywords.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgAs 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