[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [wg2] in support of single-arity procedural syntax transformers
On Fri, May 13, 2011 at 10:35 AM, Eli Barzilay <eli@x> wrote:
> 25 minutes ago, Alex Shinn wrote:
>> If you want to insist on exposing the transformer signature, then
>> you're arguing that none of the other macro systems are worth
> Wrong, same post.
OK, that post doesn't actually explain what you mean, but
we talked this out on IRC and I see know what you're suggesting
(correct me if I'm wrong).
You suggest that an alternate macro system should support
_both_ their own macros and syntax-object macros natively,
that their own macros should be tagged somehow, and then
the macro expander should dispatch on the two types of macros.
So, for example, er-macro-transformer would return an object
(list 'I-am-an-ER-macro-transformer #<procedure>)
and the expander would then do something like
(define (expand-macro op expr use-env mac-env)
(cond ((er-macro-transformer? op)
((er-macro-procedure op) expr use-env mac-env))
Now, for the plain procedure to be useful expr would actually
have to be wrapped somehow, and a basic API for structuring
and destructuring syntax objects would need to be provided,
such as what R6RS provide (without syntax-case).
Yes, technically this would allow ER macros to exist alongside
bare single-arity lambda expanders. However, it's a truly hideous
hack, and defeats the whole purpose of an alternate macro
system. It's saying "yes, you can have another macro system,
but you have to implement the syntax-object system first in the
core and hack your way around that."
Just like if you have a syntax-case system, you don't want to
clutter up the core with ER macros and load them as a library,
if you have ER macros you want to load syntax-object macros
as a library. Requiring both in the core is a non-solution.
Scheme-reports mailing list