Version 5 (modified by alaric, 6 years ago) (diff)

Noted that the keywords-as-bindings issue only applies where keywords and arbitrary expressions may collide

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.

  • Is syntax-rules a keyword in this sense? Some Schemes say yes, others no.

The R6RS standard decided to use explicitly exported and defined auxiliary syntax values, where every syntax-rules literals clause matched hygienically using free-identifier=?.

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:

Particularly, symbolic equality bypasses the normal identifier equality tests used by syntax-rules, thereby violating referential transparency and hygiene in some cases.

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))
     (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. In this situation you can use keywords-as-symbols, as arbitrary expressions can never appear there; but in a case like cond, it would be impossible to export cond and all its functions without also exporting a procedure that happened to also be called else or =>.

Any others?

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