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

On 6/13/07, YC <yinso.chen at gmail.com> wrote:
>
> 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.

It is kind of a combination of two intended aspects of the design of
the PL. One: structs should be generative, so that no one can fake
anyone else's structs. Two: modules should be separately compilable,
which means that you have to have separate instantiations of modules
used at compile time (which are then discarded). The second one is
what's covered in the paper mentioned above.

I'm not sure that there isn't a better pair of designs out there that
interact better, tho.

Robby