On Saturday, Alex Shinn wrote:
> On Fri, May 13, 2011 at 6:14 PM, Eli Barzilay <eli@barzilay.org> wrote:
> >
> > It's possible to have a world where both systems are optional:
> > either you implement neither (so `syntax-rules' is implemented in
> > some completely different way, or not at all), one, both, or more.
>
> OK, so you're describing a macro plugin system, where importing the
> appropriate macro module would register a macro object predicate and
> associated applicator.

That's one way to implement it.

> The problem is it's still fairly complicated, and theoretical -
> there are no systems I know of which do this.  Chicken 3 had
> pluginable macro systems, but they were basically mutually
> exclusive.  We'd need some more work in this before we could
> standardize it.

I'm not talking about any standardization.  Further, I specifically
talked about the option of implementing only one system.

> I'm actually interested in this, so I may hack on it when I get more
> time.  But in the meantime it's simpler to just use a wrapper.
>
> The other problem is assuming that the syntax-object transformers
> are worthy of the unique position of not requiring a wrapper.  Why
> the asymmetry?

I explained that in detail in an earlier post, which you ...

> I think it's presumptuous to assume that it, or a deriviate thereof,
> is the final step in the evolution of macro systems.

... completely ignored.  I specifically explained why this is not some
kind of discrimination -- and it also explains why things turned out
as they are, with most ER/SC systems using wrappers, and syntax cases
systems not using one.  A related side effect: this setup also
achieves minimum breakage, because it follows what happens in
practice.

> I also think the "single arity is inherently superior to triple
> arity" argument is silly.

In the same post (that you ignore), I said that it's the inherent
approach used for syntax case systems -- not that it's inherently
superior.  I also said that explaining `Syntax -> Syntax' transformer
functions in class is much easier, but that's not implying "inherent
superiority" either.  I also said that if you're after a "jewel-like"
property of a macro system, then IMO `Syntax -> Syntax' is clearly
more in that direction then the 2/3/5/etc argument versions, but (a)
that's clearly a subjective opinion, and (b) I'll be the first in line
to dump "jewel-like" as an argument, for many reasons.

> That's like saying there's something wrong with vector-set! or
> substring because they take three arguments.

This analogy is indeed irrelevantly silly.

> It's also irrelevant, because there could just as easily be
> alternate macro systems which also take a single arity signature but
> use a different API and semantics from the syntax-object macro
> systems.

(a) Right, but in the current context it's important to focus on
    *existing* systems, and non syntax case macro systems that have a
    single argument input are either non-existent or uncommon enough
    that I've never seen one.

(b) Without such a system to show otherwise, formalizing the current
    practice is a far better choice as far as a standard goes.

(c) Formalizing a system that *contradicts* R6RS is ... particularly
    silly.  Regardless of R7RS being a derivative language or not
    being one.  Even more so when practically the only argument that I
    see against accomodating both is some kind of non-technical
    "discrimination" argument.  ("Non-technical" since it's easy to
    have both, or only one.)

(d) Even if the apparently unlikely case of a new macro system with
    single-arity transformer functions materializes somehow -- what
    would you expect this single input to be?

    d1. If it's some kind of a syntax value, then it's easy to combine
        with a syntax case system (eg, make this value contain
        information for both);

    d2. if it's something completely different (say, a list of a raw
        sexpr and two functions), then the *same* modularization
        argument holds, since implementing that kind of dispatch is
        just as easy.

--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports