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

Re: 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.

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/