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.
