[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 Saturday, Alex Shinn wrote:
> On Fri, May 13, 2011 at 6:14 PM, Eli Barzilay <eli@x> 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
> 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
(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