On Wed, 4 May 2011, Alaric Snell-Pym wrote:

> Personally, I always thought that comparing the symbol was the right and
> simple thing to do, but these examples have given me pause for thought.
>
> However, having 'else' and friends be bound to something in the module
> exporting 'cond' and the check being for that binding still being in
> place is fraught with issues, too - I think Andy Wingo pointed out that
> his environment has a 'compile' procedure, and an 'eval-when' that uses
> 'compile' as a keyword. Under such a system, people in such situations
> would *have* to give access to the 'compile' procedure in order to let
> people use the 'compile' keyword to 'eval-when'.

Not necessarily.  It is certainly possible to have the COMPILE keyword
in EVAL-WHEN be implicitly quoted, so it is compared as a symbol, not
an identifier.  This does not lead to problems in principle.

(If you wanted it to be even more clear that it is not an
identifier, you could even require it to be explicitly quoted, e.g.,
(eval-when 'compile), or even be a string, as in (eval-when "compile")).

The only reason for the big confusion in COND is that the keywords ELSE
and => can appear in positions where variables can also appear, and
ELSE and => can themselves be local variables.  So we need hygienic
identifier comparison to prevent macros from breaking catastrophically
as in the examples I showed.

For example, the ELSE in CASE does not have this problem.  Since no
variable can appear in its position, it would have made sense to
consider it as always implicitly quoted and compare it as a symbol.

Andre

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports