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.
On 11/23/2012 11:08 PM, John Cowan wrote:
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.
The question is: Do we want there to be a default implementation of ($quasi-value-transformer$:foo ...) as (foo ...)? (Presumably with some transformation of the '...', but I'll ignore that for now.) If so, this would still require some built-in special handling. I think there are two approaches, which are functionally equivalent duals of each other: (1) The reader returns ($quasi-value-transformer$:foo ...). If there is no binding for $quasi-value-transformer$:foo, the implementation looks for ($quasi-value$ foo ...) which has a predefined binding equivalent to (foo ...). (2) The reader returns ($quasi-value$ foo ...). The prefined binding for $quasi-value$ is to see if $quasi-value-transformer$:foo has a binding, and otherwise evaluate (foo ...). Variant (1) has the advantage in that it can be useful even in a "partial" implementation that doesn't support the more "magic" concepts for looking for bindings and transforming symbols. I.e. one can easily and portably define a macro or function for $quasi-value-transformer$:foo, and that's the more important use case. An implementation can then *optionally* provide a default implementation and/or a mechanism to override the default. There is some question as to what "a binding exists" means: Clearly one has to check for a macro at macro-expansion time. If a binding isn't found at compile-time, do we check check for a run-time (function) binding? That matches normal behavior for (foo ...). but it makes it difficult to also support a default macro binding, though a default function binding is easy enough.
Finally, and as an independent suggestion, $quasi-value-foo$ seems less clunky than $quasi-value-transformer$:foo.
I prefer the colon form as it keeps "foo" more distinct. Also, I think it may mesh better with an extended Scheme with compound symbols (so that $quasi-value-transformer$ is some kind of predefined package-name), while also working for Schemes were colon is just a regular constituent. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/