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

Re: Monkey-patching $quasi-value$



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/