[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
>> supporting,
> 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))
              (op expr))))

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