[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Infoset Unicode BOM --Richard Tobin