<br><div><span class="gmail_quote">On 6/13/07, <b class="gmail_sendername">Robby Findler</b> <<a href="mailto:robby@cs.uchicago.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">robby@cs.uchicago.edu
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > Thanks for the great explanation Jens - this makes great sense - but is<br>> > there a way to prevent struct being evaluated twice, once for (require) and<br>> > once for (require-for-syntax)? In the example you cited the double eval is
<br>> > clearly intended because each define-struct is enclosed lexcially and it<br>> > makes sense that they are different structs (like enclosed lambda &<br>> > variables are different), but IMHO (require-for-syntax) and (require)
<br>> > evaluate the same code twice is _surprising_ (I thought it's more like<br>> > "importing" names to the transformation environment) - love to hear your and<br>> > others' take on whether this is expected.
<br><br>> It is expected. For more on the rationale, see this paper:<br><br>> <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've seen this paper a few times, admittedly not fully grokking it ;)<br><br>I don't mean to ask whether the separation evaluation of compile-time versus run-time is expected. 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. 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've heard rumors about r6rs) it might become easier to walk into the same situation then. So perhaps there might be need to disclaim more visibly in the future if this is indeed intended by design - that don'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>