On Fri, May 13, 2011 at 10:35 AM, Eli Barzilay <eli@barzilay.org> 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 like: (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)) (else (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. -- Alex _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports