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'.
>
> If it's bound to something else, then it won't work in
> `cond', whether there it had any binding in (scheme base)
> or not. If you want to import a module that binds "=>",
> you need to rename it or except it.
>
> The only thing binding it to something would change
> is require programmers to go through the effort to always
> specifically import it.
This discussion has been had in R6RS and based on the discussion there the
decision was made to make it and other literals bound in the base. There were
many reasons for it, among others:
- 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 we cannot rename one of these sets, eiher the SYNTAX-CASE
or the MATCH code-walker is going ot
become confused if there are nested user matcher expressions.
- A teacher may want to make an R5RS module that excludes use of post-R6RS
literals such as _ in SYNTAX-RULES and instead treats _ as an ordinary
variable. Can only be done if _ is bound.
- We cannot easily create a teaching language where => clauses are not allowed
in COND unless => is bound.
- An unbound ELSE is anglo-chauvinism. Most of the world is not anglo. A
french elementary school teacher may want to translate ELSE for her
students. Can only be done if bound.
- If literals are not bound, the teacher can translate QUOTE for her students
but cannot translate UNQUOTE.
- The semantics of FREE-IDENTIFIER=? which is used to compare literals - should
unbound identitifiers in different modules be free-identifier=? if they have
the same symbol? This is not obvious to me, and as an implemento I know
from experience that it can complicate a macro explansion system to insist
upon it
- Typically, such literals mcan be bound to a macro expanding to a syntax error,
which is extremely useful for error checking.
- A lot of these literals are common enough names that users are likely to
stop on them by accident. Fi they are bound, the expander will thorw an
redefinition error. If they are unbound, however, code will just mysteriously
stop working.
Andre
