Am Sa., 19. Okt. 2019 um 11:39 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > In other words - locations of posittional parameters aren't subject of
> > hyegene; we don't
> > import a procedure with its argument swapped, for example.  Keyword
> > arguments are just
> > another way of specifying parameters, it's less about names.
>
> This is a good analogy, unless I've missed something. If the numbers of
> positional arguments had to be written explicitly:
>
> (foo 1 "first positional value"
>       2 "second positional value"
>       3 "third positional value"
>       abc: "value of keyword arg abc"
>       def: "value of keyword arg def")
>
> Then it wouldn't matter that 1, 2 and 3 are not hygienic either. Like
> the keywords, they are just markers. Isn't hygiene only a concern when
> the identifier is used as a variable instead of a marker? (In other
> words: If he identifier resolves to something else, it can resolve to
> the wrong thing if we don't have hygiene. Since markers don't resolve to
> anything else, there is no possibility of confusion.)

Hygiene is also a concern when identifiers are used as markers. This
happens when they are record field names in record-type definitions.
It also when they are used as keywords in `syntax-rules' macros (i.e.
when they occur in the list of identifiers that are to be matched
literally in `syntax-rules'). For example, `else' and `=>' are bound
to some syntactic value by `(scheme base)', and when the transformer
associated to `cond' expands such a `cond' form, it checks against the
binding and not the name (see the definition of `free-identifier=?' in
the R6RS). For example, the following evaluates to the symbol `ok':

(import (rename (scheme base) (else otherwise)))
(cond
 (#f 'fail)
 (otherwise 'ok))

Scheme would lose a bit of its elegance if keywords to procedures
behaved differently than keywords in the various derived expression
types.

The analogy to positional arguments is actually one in favor of
hygienic keywords: Think of a CPS transformer that takes a piece of
Scheme code and transforms it into a CPS-version of it. For this,
every procedure will be rewritten so that it receives an extra
argument, taking the continuation. The simplest way to do is to have
the continuation argument the first positional argument and to move
all other arguments one position to the right.

The analogy with keyword arguments would be a source transformer (e.g.
a sophisticated macro transformer) that wants to add some extra
keyword argument. It will have to generate a keyword that is provably
different to any other keyword ever used in the program. If keywords
are identifiers, the needed renaming facility is already built into
Scheme and its hygienic macro system.

There is one more argument in favor of hygienic keywords (should they
become part of a future Scheme standard) based on first principles:
The Scheme standard does not allow inspection of procedures, e.g.
given a procedure, there is no portable way to find out the arity of
this procedure at runtime. (One reason is that the arity of some
procedures — think of case-lambda — is not a well-defined concept;
another reason is that it could forbid some implementation models.)
Thus, the interface of a procedure (its calling protocol) is at most a
compile-time and not a runtime-concept. Thus, keywords should
principally be compile-time and not runtime constructs as well
(irregardless of how they are implemented). Hygienic identifiers are
such compile-time names, while symbols are inherently runtime names.