On Wed 04 May 2011 22:20, Alaric Snell-Pym <alaric@snell-pym.org.uk> writes:

> 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.

On my part, I never understood all of the implications, and still don't
understand them entirely; I think that comes from working with a system
in which `else' is unbound.  Thanks to Andre for being patient with us,
though :)

> 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'.

Procedural macros allow the user to make a choice between matching
keywords as datums or identifiers.  In this case I changed to match the
eval-when situations as datums, because identifiers can't sensibly go
there.  In the cond case, where a datum or an identifier may appear in
the same place, we probably will need to match keywords as identifiers.

Is that a general rule?  That if your macro grammar is unambiguous
regarding in that keywords can only be seen in places where identifiers
are not valid -- like `case' -- then this point is largely moot; whereas
with `cond', which needs to compare `else' and `=>' as
identifiers... dunno where I'm going with this.

> We've heard a lot of reasons why each possible solution is wrong.
> Clearly, we have a tough decision to make.

Heh, I realize you're trying to direct things in a productive direction;
sorry for the noise here.  But I have enjoyed this discussion on the
list; it's made things clearer for me.

I think that in the end, in Guile, we'll probably end up doing the
(define-syntax else ...) thing in 2.2.  It seems like the right thing.
But perhaps great arguments on the Keywords wiki page will make me
change my mind :)

Happy scheming,

Andy
--
http://wingolog.org/

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