Email list hosting service & mailing list manager


Monkey-patching $quasi-value$ John Cowan 24 Nov 2012 07:08 UTC

When I started to read the current draft carefully, I was disturbed by
the translation of &#foo[...] into ($quasi-value$ foo ...).  If it's
to be allowed to implement $quasi-value$ with a syntax-rules macro,
it would be necessary to redefine the macro every time a new keyword is
added in order to add appropriate syntax rules.  This would be painful.

Then I saw the discussion of how the default $quasi-value$ macro would
dispatch to $quasi-value-transformer$:foo.  This is nicely decentralized,
but it becomes impossible to write $quasi-value$ using syntax-rules
(or at least I think it is -- I never quite know what can and cannot be
done by syntax-rules abuse).  Most Schemes have some sort of low-level
macro support, but neither R5RS nor R7RS require it.

I suggest, therefore, that the burden be put on the Scheme reader, and
that &#foo[...] be desugared to ($quasi-value-transformer$:foo ...) in the
first place, eliminating the dispatching macro $quasi-value$ altogether.
This allows such a transformer to be written as a low-level macro,
a syntax-rules macro, or even a procedure.

Finally, and as an independent suggestion, $quasi-value-foo$ seems less
clunky than $quasi-value-transformer$:foo.

--
XQuery Blueberry DOM                            John Cowan
Entity parser dot-com                           xxxxxx@ccil.org
    Abstract schemata                           http://www.ccil.org/~cowan
    XPointer errata
Infoset Unicode BOM                                 --Richard Tobin