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
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
