<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="courier new, monospace">Hi,</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default">

<font face="courier new, monospace">I am trying to understand hygienic macro expansion by looking into </font></div><div class="gmail_default"><font face="courier new, monospace">the algorithms, in the paper "Macros That Work" and "Syntactic </font></div>

<div class="gmail_default"><font face="courier new, monospace">Abstraction in Scheme".  Any of them may not exactly be what is </font></div><div class="gmail_default"><font face="courier new, monospace">implemented in Racket but presumably the essential ideas are not </font></div>

<div class="gmail_default"><font face="courier new, monospace">that different. Currently I encounter two problems in understanding:</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div>

<div class="gmail_default"><font face="courier new, monospace">1. If I understand these algorithms correctly, the lexical environment </font></div><div class="gmail_default"><font face="courier new, monospace">of a macro definition is saved into a syntactic closure, so that free </font></div>

<div class="gmail_default"><font face="courier new, monospace">variables inserted into the body of a macro will not be captured by any </font></div><div class="gmail_default"><font face="courier new, monospace">binding construct in the context of a macro call. But I notice that </font></div>

<div class="gmail_default"><font face="courier new, monospace">both expansion algorithms always rename bound variables of some core </font></div><div class="gmail_default"><font face="courier new, monospace">binding constructs, like lambda. I see that if such a core binding </font></div>

<div class="gmail_default"><font face="courier new, monospace">construct is inserted into the body of a macro, its bound variables </font></div><div class="gmail_default"><font face="courier new, monospace">should be renamed to avoid capturing free variables from the context of </font></div>

<div class="gmail_default"><font face="courier new, monospace">the macro call. But if such a core binding construct does not occur in </font></div><div class="gmail_default"><font face="courier new, monospace">the body of a macro, its bound variables do not need be renamed. So I </font></div>

<div class="gmail_default"><font face="courier new, monospace">wonder whether this always renaming strategy is simply a disregard of </font></div><div class="gmail_default"><font face="courier new, monospace">distinguishing these two cases. If so, why do these algorithms do not </font></div>

<div class="gmail_default"><font face="courier new, monospace">do the case distinction? Because it is too difficult or because it </font></div><div class="gmail_default"><font face="courier new, monospace">would further complicate the algorithms?</font></div>

<div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">2. Both algorithms also always rename pattern variables. I was told </font></div>

<div class="gmail_default"><font face="courier new, monospace">that this is because a macro can insert another macro definition into </font></div><div class="gmail_default"><font face="courier new, monospace">its body. Thus similar to the case of inserting a core binding construct, </font></div>

<div class="gmail_default"><font face="courier new, monospace">the pattern variables should also be renamed. Although I can imagine </font></div><div class="gmail_default"><font face="courier new, monospace">this, I think I would appreciate a good example that illustrates this</font></div>

<div class="gmail_default"><font face="courier new, monospace">kind of capture.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Thank you for your attention.</font></div>

<div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Cheers,</font></div><div class="gmail_default"><font face="courier new, monospace"><br>

</font></div><div class="gmail_default"><font face="courier new, monospace">Yi</font></div></div></div>