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