This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home. For a version of this page that may be more recent, see Keywords in WG2's repo for R7RS-large.


2011-05-05 03:57:22
1Summarised what little I know about the issueshistory

There seems to be a serious issue with how we handle keywords (by which we mean, things like the else in cond). R5RS was vague on the matter, and each choice of implementation approach seems to have issues.

Let's summarise the issues with different approaches.

Keywords as symbols

One approach is to say that the implementation of cond must match a symbol called else - so it's purely symbolic equality, rather than bothering about lexical environments.

Problems: See this thread:

Keywords as Bindings

Under this scheme, else is bound to something (a value? a macro? a pineapple?) along with the definition of cond, and we check that the same binding is in place when else is used in the wild.

This means that if we do:

(let ((else #f)) (cond (else 1))

...we'll get an error, not 1, as we've rebound else; that arm of the cond will evaluate else and get #f, so no arm of the cond matches.

However, it has another issue. Andy Wingo, I believe, gave an example of a module that exposes both compile (a procedure) and eval-when (a macro that uses compile as a keyword). It's then impossible to expose eval-when into a sandbox, still able to use the compile keyword, without then also giving them the compile procedure.

Any others?

Please add alternative implementation techniques here, and discuss their problems and characteristics.