[plt-scheme] create complex object @ compile time but made available @ run time?

On 6/13/07, Robby Findler <robby at cs.uchicago.edu > wrote:
>
> > > Thanks for the great explanation Jens - this makes great sense - but
> is
> > > there a way to prevent struct being evaluated twice, once for
> (require) and
> > > once for (require-for-syntax)?  In the example you cited the double
> eval is
> > > clearly intended because each define-struct is enclosed lexcially and
> it
> > > makes sense that they are different structs (like enclosed lambda &
> > > variables are different), but IMHO (require-for-syntax) and (require)
> > > evaluate the same code twice is _surprising_ (I thought it's more like
> > > "importing" names to the transformation environment) - love to hear
> your and
> > > others' take on whether this is expected.
>
> > It is expected. For more on the rationale, see this paper:
>
> > http://www.cs.utah.edu/plt/publications/macromod.pdf


Thanks Robby - I've seen this paper a few times, admittedly not fully
grokking it ;)

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.

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 ;)

Thanks!
yinso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070613/c1ec4130/attachment.html>