[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Monkey-patching $quasi-value$

This page is part of the web mail archives of SRFI 108 from before July 7th, 2015. The new archives for SRFI 108 contain all messages, not just those from before July 7th, 2015.

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                           cowan@xxxxxxxx
    Abstract schemata                           http://www.ccil.org/~cowan
    XPointer errata
Infoset Unicode BOM                                 --Richard Tobin