On Sat, 16 Apr 2011, Andre van Tonder wrote:
> On Sat, 16 Apr 2011, Alex Shinn wrote:
>
>>> - p57. How do we implement "=>" exported from (scheme base) module ?
>>> "=>" itself is not a syntax or a procedure (i think).
>>
>> As you say, there is no "=>" bound in (scheme base).
>> So long as it's not bound in the usage context it will
>> thus work with `cond'.
Here is the roiginal R6RS formal comment and response:
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.
