<br><div><span class="gmail_quote">On 6/13/07, <b class="gmail_sendername">Robby Findler</b> &lt;<a href="mailto:robby@cs.uchicago.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">robby@cs.uchicago.edu
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; &gt; Thanks for the great explanation Jens - this makes great sense - but is<br>&gt; &gt; there a way to prevent struct being evaluated twice, once for (require) and<br>&gt; &gt; once for (require-for-syntax)?&nbsp;&nbsp;In the example you cited the double eval is
<br>&gt; &gt; clearly intended because each define-struct is enclosed lexcially and it<br>&gt; &gt; makes sense that they are different structs (like enclosed lambda &amp;<br>&gt; &gt; variables are different), but IMHO (require-for-syntax) and (require)
<br>&gt; &gt; evaluate the same code twice is _surprising_ (I thought it&#39;s more like<br>&gt; &gt; &quot;importing&quot; names to the transformation environment) - love to hear your and<br>&gt; &gt; others&#39; take on whether this is expected.
<br><br>&gt; It is expected. For more on the rationale, see this paper:<br><br>&gt; <a href="http://www.cs.utah.edu/plt/publications/macromod.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.cs.utah.edu/plt/publications/macromod.pdf
</a></blockquote><div>
<br>Thanks Robby - I&#39;ve seen this paper a few times, admittedly not fully grokking it ;)<br><br>I don&#39;t mean to ask whether the separation evaluation of compile-time versus run-time is expected.&nbsp; I mean whether the interaction between struct creation and the phase separation is intended by design, as in that it is designed to intentionally not allowing users to return struct(-based) values in macros and use it at runtime.&nbsp; This makes struct special comparing to other ordinary values. 
<br><br>This right now is probably an edge case that people would use macro to compute structs, but as macro becomes easier to use (or so I&#39;ve heard rumors about r6rs) it might become easier to walk into the same situation then.&nbsp; So perhaps there might be need to disclaim more visibly in the future if this is indeed intended by design - that don&#39;t use macro to compute things besides basic values and syntax and use it @ run-time ;)
<br><br>Thanks!<br>yinso <br><br></div></div>