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).
These instances are reasonable and I'm not opposing it at all. I just think keywords are different.
Actually, keyword argument markers don't even need to be symbols or identifiers; they can be any
literal data, as far as they can be compared both at compile time and runtime (preferably, by eq?).
Runtime comparison is necessary, since keyword-value list can be (and need to be) passed around
via rest arguments.
What do you say about necessity of renaming conflicting keywords from different libraries? Or
am I missing something and worring nonexistent problem?
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.