<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 14, 2015, at 8:14 PM, Thomas Lynch wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Matthias thank you for fielding my question, though two things are not clear. I hope you or someone might clarify. <div><br></div><div>Firstly, is there a reason to prefer the macro you present over the first one given in the original post. I believe they both work. Neither uses the more elegant syntax-rule.</div></div></blockquote><div><br></div><div><br></div><div>Code that works is fine. Code that clearly explains its intention is better. Since syntactic extensions are (basically) extensions to the grammar, their specification ought to bring across (a) what kind of new expressions programmers may write down and (b) what these new expressions mean. I think separating these cleanly is also important. </div><div><br></div><div>With syntax-case, which isn't all that different from syntax-rules, you get (a) easily: </div><div><br></div><div> (with-tables stem body ...)</div><div><br></div><div>Compare this to your three or four lines that stx apart. When your extension is even more complicated, you definitely want this pattern matching notation because it is close to the way people write grammars and because you can automatically check certain properties (see syntax-parse). </div><div><br></div><div>For (b), constructing a piece of syntax manually with backquote, comma, splice is again much more complicated than writing down a rewrite rule. In particular, you get a really good handle at the manipulation of scope, which is one of the primary functions of syntactic extensions. </div><div><br></div><div>Racket like Scheme like Lisp is about being able abstract boiler plate. Syntax-case abstracts your boiler plate for (a) and (b). </div><div><br></div><div>Ideally, I would like to separate (a) from (b) so that programmers can specify (a) at the module boundary, just like contracts for functions. That's what I started Ryan on and we ended up syntax-parse. It' s a fantastic first step but there is work left to do. Probably another dissertation. </div><div><br></div><div><br></div><blockquote type="cite"><div dir="ltr"><div>Secondly, and this is the question I'm really getting at, is there a reason that the operands given to syntax-rules must have identifiers within lexical scope at the point of the macro call, rather than lexical scope at the point of their use within the macro? </div></div></blockquote><div><br></div><div>Lexical scope is critical for program comprehension. Programmers read programs a lot more often than they write them. Lexical scope guarantees that when they read programs all identifiers are resolved (bound) to a declaration (binding position) that can be found by reading the text -- not running the program. By finding it in the text w/o running it, you have a better chance of predicting what the program does when you run it. </div><div><br></div><div>Macros rewrite program text. In the process, they substitute use-site code into macro-definition code and macro-definition code is substituted into use-site code. Each substitution may affect lexical scope when performed without respect to lexical scope. Each substitution may thus bind variables to binding occurrences that you can only figure out by running code. Enforcing that </div><div><br></div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>use-site variables are bound by use-context</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>macro-site variables are bound by macro-contexts </div><div><br></div><div>___by default___ is called hygienic expansion and almost always gives you what you want. </div><div><br></div><div>On rare occasion, an extension of Racket's grammar also needs to break these default rules. syntax-case/parse allow programmers to break those rules in a way that is still easy to read off from the code. </div><div><br></div><div>That's why it's the right way to go about syntax extensions. -- Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><br>Off hand the latter seems to be the proper behavior for a macro, i.e. perhaps this is a bug? Can anyone here tell me why it behaves like this?<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 4:12 AM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
You want something like this:<br>
<br>
(define-syntax (with-tables stx)<br>
(syntax-case stx ()<br>
[(with-tables stem body ...)<br>
(let ([table-author (datum->syntax stx 'table-author)]<br>
;; ... ditto for other identifiers for which you wish to break lexical scope<br>
)<br>
#`(let ([table-publication (string-append stem "_publication")]<br>
[#,table-author (string-append stem "_author")]<br>
<span class=""> [table-bridge-publication-author (string-append stem "_bridge_publication_author")]<br>
[table-unique-counters (string-append stem "_unique_counters")])<br>
</span> body ...))]))<br>
<br>
(with-tables "x" table-author)<br>
<br>
;; ---<br>
<br>
To achieve this with syntax-rules would be, well, hard.<br>
<br>
;; ---<br>
<br>
The accepted way of writing this macro is:<br>
<br>
(define-syntax (with-tables stx)<br>
(syntax-case stx ()<br>
[(with-tables stem (table-author<br>
;; ... add other names you wish to bind in body<br>
)<br>
body ...)<br>
#`(let ([table-publication (string-append stem "_publication")]<br>
<span class=""> [table-author (string-append stem "_author")]<br>
[table-bridge-publication-author (string-append stem "_bridge_publication_author")]<br>
[table-unique-counters (string-append stem "_unique_counters")])<br>
body ...)]))<br>
<br>
</span>(with-tables "x" (table-author) table-author)<br>
<br>
<br>
<br>
</blockquote></div><br></div>
</blockquote></div><br></body></html>