Formal comment #164 (defect) Treatment of literal keywords Reported by: Andre van Tonder Version: 5.92 Type : omission; Component : Almost all components Summary It is not stated whether various literal keywords refer to bindings. Description It is unclear whether literal keywords such as unquote, =>, ..., _, else, protocol, fields, etc., refer to bindings, and if so, to what they are bound. Typically, such literals may be bound to a macro expanding to a syntax error, which is a good idea for error checking. There is a very strong argument for requiring these literals to be bound. If they refer to bindings, they can be exported, imported, prefixed, renamed, or excluded. These are useful operations, and I think it is important for users to be able to rely on them to work portably. Consider, for example, using syntax case together with a user-written matcher library, both of which use the identifiers ... and _ with separate meanings (here prefixing or renaming would be useful). If it were decided that they do not refer to bindings, on the other hand, then they would be "always available" in the sense of the first paragraph of 6.3, which should then be changed to reflect this (this would not, in my opinion, be a good thing, though). Suggestion Consider stating that literal identifiers refer to bindings, so that they can be imported/exported/renamed/excluded. RESPONSE: Agreed. Identifier matching is clearly the right choice for literals in positions where non-literals can appear; such is the case for `...' and `_' (see formal comment 159), as well as `=>' and `else'. The choice is less clear for literals that appear in positions that can have only literals, such as `fields' and `mutable' in a `define-record-type' form. An advantage of binding is that it allows renaming on import and export, and it allows hiding to prevent access to certain constructs. A disadvantage is that binding may introduce collisions when literals overlap symbolically with other bindings and with the literals of other forms. The deciding advantage of binding, though, is that it's consistent with the right choice for literals in expression positions. Therefore, in the next draft of R6RS, every literal will correspond to an identifier that is exportd by an appropriate library. Using such an identifier out of place (i.e., as an expression where it is not specifically recognized as a literal) will be treated as a syntax violation. Note that `and', `or', `>', etc. in an `import' clause are not bound by imports or definitions, since the `import' clauses themselves determine initial bindings. Thus, literals in an `import' clause do not collide with other bindings, such as those supplied by `(r6rs base)'. The same is true for literals in an `export' clause, or the `library', `import', and `export' keywords themselves.