<br><div class="gmail_quote">On Thu, Jul 14, 2011 at 9:58 PM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">25 minutes ago, Markku Rontu wrote:<br> > > > <a href="http://hipster.home.xs4all.nl/lib/scheme/gauche/define-syntax-primer.txt" target="_blank">http://hipster.home.xs4all.nl/lib/scheme/gauche/define-syntax-primer.txt</a><br> </div>> [...]<br> <div class="im">><br> > Still, I count it as good eye opening material :)<br> <br> </div>Well, it has a heavy focus on "computations via rewriting", which can<br> of course be an eye opener, but off-topic when talking about practical<br> macro writing. (It still is practical, if you're confined to R5RS for<br> portability, but we're now in a racket context.)<br> <div class="im"><br></div></blockquote><div>Ok maybe that style as you say "computations via rewriting" is what brings the bad C++ memories. But it opened my eyes as to what is possible with syntax-rules. And sometimes I use it with syntax-case too. <br> </div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> > Granted your cited blog post is good too but it's not a complete<br> > tutorial.<br> <br> </div>It's inteneded as a quick thing for people who are familiar with<br> symbolic `defmacro' things.<br> <div class="im"><br> <br> > > If you're working in Racket, it makes much more sense to really use<br> > > its syntax system rather than stick to those tricks.<br> > ><br> > However, I find syntax-case to be very similar if you proceed to it<br> > as next step from syntax-rules. I mean that if you take it as an<br> > improved syntax-rules, you will likely end up using it just like<br> > syntax-rules except for the part about breaking hygiene. This is<br> > just my experience.<br> <br> </div>Not at all. The main addition is exactly what you complained about:<br> having the full language. Here's an implementation of a function<br> application with reversed arguments, with `syntax-rules':<br> <br> (define-syntax rapp<br> (syntax-rules ()<br> [(rapp f x ...) (rapp* f (x ...))]))<br> (define-syntax rapp*<br> (syntax-rules ()<br> [(rapp* f (x0 x ...) r ...) (rapp* f (x ...) x0 r ...)]<br> [(rapp* f () r ...) (f r ...)]))<br> <br> Can you see the reversal? It's of course possible -- and even an<br> instance of such eye openning, but I really wouldn't call that<br> obvious. (And un-obvious is bad -- it leads to surprising bugs.)<br> <br></blockquote><div>Yeah, it's obvious after the tutorial I linked ;-) <br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Here is the same using `syntax-case':<br> <br> (define-syntax (rapp stx)<br> (syntax-case stx ()<br> [(rapp f x ...) #`(f #,@(reverse (syntax->list #'(x ...))))]))<br> <br> and now the reversal is explicit -- it says "reverse"...<br> <br> There's of course the naive translation of `syntax-rules' to<br> `syntax-case', leading to the same bad code as the first example.<br> That's why the first thing that should be made obvious is that there<br> is no magic here -- these are just plain values. Once *that* is<br> clear, it should also be clear that such a translation is a bad idea.<br> <br></blockquote><div><br>I would not call this piece of code much more obvious, it has too much line noise for my comfort :-)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> As an antidote to such illusions of black magic, here's another<br> version that doesn't even use `syntax-case':<br> <br> (define-syntax (rapp stx)<br> (let ([l (cdr (syntax->list stx))])<br> (datum->syntax stx (cons (car l) (reverse (cdr l))))))<br> <div class="im"><br></div></blockquote><div><br>Thanks anyway for these, they are more of what I was talking about. I do use "the full power of Racket" when writing my macros. Like introducing new names through string manipulation and syntax->datum and datum->syntax. Still that part usually looks ugly and un-Rackety to me. Have to ponder more why it feels so.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> <br> > > Read that blog post: it shows you how you can use plain racket<br> > > code to write macros -- and it introduces some of the tools that<br> > > make it easy to deal with syntax values.<br> ><br> > I think what is mainly missing is a bit more positive publicity in<br> > this area. A great collection of tools for writing macros exists,<br> > and obviously great things are being written using them (TR<br> > etc.). Just need to produce enough material so that the search<br> > engines start to find the good stuff.<br> <br> </div>That is a social problem:<br> - There are many people who still think that macros are a bad idea in<br> general, and advocate that idea.<br> - From the peole who manage to get passed that propaganda line, there<br> are people who think that there's nothing wrong with plain CPP-style<br> textual macros, and advocate that idea.<br> - From the peole who manage to get passed that propaganda line, there<br> are people who think that symbolic macros are superior, and advocate<br> that idea.<br> - From the peole who manage to get passed that propaganda line, there<br> are people who think that `syntax-rules' are better since they don't<br> get phases, and advocate that idea.<br> <div><div></div><div class="h5"><br></div></div></blockquote><div><br>Who else to praise the awesomeness of Racket macros and syntax-case and phase levels if not the Racket people? If you get them young then they might not need to pass all those filters :-)<br> <br>-Markku<br></div></div>